Question about optimizer.cpp and inlining

[Kai]

Hi!

I have a question about optimizer.cpp.

For me, it looks like optimizer.cpp duplicates a lot of
lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good
reason not to use this builder? (E.g. clang does use it!)

I rewrote optimizer.cpp to use PassManagerBuilder. This changes the
inlining behaviour. If not explicit disabled then inlining is always
performed but with different threshholds. This sounds reasonable for me.
The net result is that the commandline option -enable-inlining goes away
(-disable-inlining is still present).

What surprises me is the fact the global.params.useInline (which guides
the DMD frontend inliner) is always false. Is this intentional?

I really like to use PassManagerBuilder because the LLVM folks update
this class with new stuff (e.g. the vectorizer). But what should the
-inline option from ldmd2 do?

Possible solutions:
- It is an oversight that the DMD frontend inliner is not used. In this
case I would introduce a new -inline option in ldc2 to enable the DMD
frontend inliner.
- Otherwise the -inline option of ldmd2 becomes a no-op.

Any suggestions?

Regards
Kai

[Alex Rønne Petersen]

On Sat, Sep 8, 2012 at 2:13 PM, Kai <k...@redstar.de> wrote:
> Hi!
>
> I have a question about optimizer.cpp.
>
> For me, it looks like optimizer.cpp duplicates a lot of
> lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good reason
> not to use this builder? (E.g. clang does use it!)

I think it was only added recently, so it's probably just due to
historical reasons.

>
> I rewrote optimizer.cpp to use PassManagerBuilder. This changes the inlining
> behaviour. If not explicit disabled then inlining is always performed but
> with different threshholds. This sounds reasonable for me. The net result is
> that the commandline option -enable-inlining goes away (-disable-inlining is
> still present).

I'm not sure if inlining by default is a good idea. I'm of the opinion
that, if no optimization options are passed, the compiler should make
the debugging experience as good as possible.

>
> What surprises me is the fact the global.params.useInline (which guides the
> DMD frontend inliner) is always false. Is this intentional?

Probably. LLVM most likely does inlining better.

>
> I really like to use PassManagerBuilder because the LLVM folks update this
> class with new stuff (e.g. the vectorizer). But what should the -inline
> option from ldmd2 do?

Just make sure /some/ sort of inlining is enabled - I don't think it
matters whether that's DMD's inliner or LLVM's.

>
> Possible solutions:
> - It is an oversight that the DMD frontend inliner is not used. In this case
> I would introduce a new -inline option in ldc2 to enable the DMD frontend
> inliner.
> - Otherwise the -inline option of ldmd2 becomes a no-op.
>
> Any suggestions?
>
> Regards
> Kai
>

> --
> You received this message because you are subscribed to the Google Groups
> "LDC - the LLVM D compiler" group.
> To post to this group, send email to ldc...@googlegroups.com.
> To unsubscribe from this group, send email to
> ldc-dev+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ldc-dev?hl=en.
>

[Kai]

On 08.09.2012 16:10, Alex R�nne Petersen wrote:
> On Sat, Sep 8, 2012 at 2:13 PM, Kai <k...@redstar.de> wrote:
>> Hi!
>>
>> I have a question about optimizer.cpp.
>>
>> For me, it looks like optimizer.cpp duplicates a lot of
>> lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good
reason
>> not to use this builder? (E.g. clang does use it!)
>
> I think it was only added recently, so it's probably just due to
> historical reasons.

Yes, you are right. The PassManagerBuilder was introduced with LLVM 3.0.
I missed that fact.

>
>>
>> I rewrote optimizer.cpp to use PassManagerBuilder. This changes the
inlining
>> behaviour. If not explicit disabled then inlining is always
performed but
>> with different threshholds. This sounds reasonable for me. The net
result is
>> that the commandline option -enable-inlining goes away
(-disable-inlining is
>> still present).
>
> I'm not sure if inlining by default is a good idea. I'm of the opinion
> that, if no optimization options are passed, the compiler should make
> the debugging experience as good as possible.

My explanation is a bit misleading. At default the AlwaysInlinerPass is
run. This pass inlines functions that are marked as "always_inline". To
get no inlining at all you have to use -disable-inlining.
Clang uses the same strategy. I would expect no negative impact on the
debugging experience.

>
>>
>> What surprises me is the fact the global.params.useInline (which
guides the
>> DMD frontend inliner) is always false. Is this intentional?
>
> Probably. LLVM most likely does inlining better.

Yes, but in this case we should think about removing the code.

[David Nadlinger]

Hi Kai,

On Sat, Sep 8, 2012 at 2:13 PM, Kai <k...@redstar.de> wrote:

> For me, it looks like optimizer.cpp duplicates a lot of
> lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good reason
> not to use this builder? (E.g. clang does use it!)

No, there is no reason I'd be aware of – in fact, replacing our code
with PassManagerBuilder is also on my todo list. I was looking for
benchmarks to make sure the changed pass scheduling doesn't lead to
_worse_ performance, though (IIRC, the LDC setup includes quite a few
duplicate runs) – but that might just be overly cautious.

> I rewrote optimizer.cpp to use PassManagerBuilder. This changes the inlining
> behaviour. If not explicit disabled then inlining is always performed but
> with different threshholds. This sounds reasonable for me. The net result is
> that the commandline option -enable-inlining goes away (-disable-inlining is
> still present).

LDC currently also performs inlining without -inline being passed on
-O3 (and higher, but -O<4-5> are really the same as -O3 atm). When I
looked at Clang some while back, I found the inline handling strategy
to be quite sensible – maybe we could just copy it? Doesn't Clang also
have a flag similar to "enable-inling"?

> What surprises me is the fact the global.params.useInline (which guides the
> DMD frontend inliner) is always false. Is this intentional?

Yes, this is intentional, the DMD inliner tends to do more harm than
good (which is probably the reason why it isn't enabled by default in
-O builds). I'll add a comment to the source.

> - Otherwise the -inline option of ldmd2 becomes a no-op.

It would become a no-op for higher optimization levels, just as it is now, no?

David

[Kai]

Hi David,

On 08.09.2012 19:06, David Nadlinger wrote:
> Hi Kai,
>
> On Sat, Sep 8, 2012 at 2:13 PM, Kai <k...@redstar.de> wrote:
>> For me, it looks like optimizer.cpp duplicates a lot of
>> lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good reason
>> not to use this builder? (E.g. clang does use it!)
>

> No, there is no reason I'd be aware of � in fact, replacing our code

> with PassManagerBuilder is also on my todo list. I was looking for
> benchmarks to make sure the changed pass scheduling doesn't lead to
> _worse_ performance, though (IIRC, the LDC setup includes quite a few

> duplicate runs) � but that might just be overly cautious.

Maybe you should put your todo list into the wiki pages? We could use
the wiki to indicate who is working on what item to avoid duplicate work.
I create a pull request for the optimizer. Then we can try to benchmark
the performance.

>> I rewrote optimizer.cpp to use PassManagerBuilder. This changes the inlining
>> behaviour. If not explicit disabled then inlining is always performed but
>> with different threshholds. This sounds reasonable for me. The net result is
>> that the commandline option -enable-inlining goes away (-disable-inlining is
>> still present).
>
> LDC currently also performs inlining without -inline being passed on
> -O3 (and higher, but -O<4-5> are really the same as -O3 atm). When I
> looked at Clang some while back, I found the inline handling strategy

> to be quite sensible � maybe we could just copy it? Doesn't Clang also

> have a flag similar to "enable-inling"?

I copied the strategy from the opt tool. The Clang strategy is similar.
Clang has a -finline option which is ignored. Only -fno-inline is honoured.

>> What surprises me is the fact the global.params.useInline (which guides the
>> DMD frontend inliner) is always false. Is this intentional?
>
> Yes, this is intentional, the DMD inliner tends to do more harm than
> good (which is probably the reason why it isn't enabled by default in
> -O builds). I'll add a comment to the source.

This would be good. I really wondered if this was a real decision or not.

>> - Otherwise the -inline option of ldmd2 becomes a no-op.
> It would become a no-op for higher optimization levels, just as it is now, no?
>
> David
>

Kai

[Tomas Lindquist Olsen]

Hi folks,

On Sat, Sep 8, 2012 at 8:21 PM, Kai <k...@redstar.de> wrote:

Hi David,

On 08.09.2012 19:06, David Nadlinger wrote:

Hi Kai,

On Sat, Sep 8, 2012 at 2:13 PM, Kai <k...@redstar.de> wrote:

For me, it looks like optimizer.cpp duplicates a lot of
lib/Transform/IPO/PassManagerBuilder.cpp from LLVM. Is there a good reason
not to use this builder? (E.g. clang does use it!)

No, there is no reason I'd be aware of – in fact, replacing our code

with PassManagerBuilder is also on my todo list. I was looking for
benchmarks to make sure the changed pass scheduling doesn't lead to
_worse_ performance, though (IIRC, the LDC setup includes quite a few

duplicate runs) – but that might just be overly cautious.

Maybe you should put your todo list into the wiki pages? We could use the wiki to indicate who is working on what item to avoid duplicate work.
I create a pull request for the optimizer. Then we can try to benchmark the performance.

I rewrote optimizer.cpp to use PassManagerBuilder. This changes the inlining
behaviour. If not explicit disabled then inlining is always performed but
with different threshholds. This sounds reasonable for me. The net result is
that the commandline option -enable-inlining goes away (-disable-inlining is
still present).

LDC currently also performs inlining without -inline being passed on
-O3 (and higher, but -O<4-5> are really the same as -O3 atm). When I
looked at Clang some while back, I found the inline handling strategy

to be quite sensible – maybe we could just copy it? Doesn't Clang also

have a flag similar to "enable-inling"?

I copied the strategy from the opt tool. The Clang strategy is similar. Clang has a -finline option which is ignored. Only -fno-inline is honoured.

What surprises me is the fact the global.params.useInline (which guides the
DMD frontend inliner) is always false. Is this intentional?

Yes, this is intentional, the DMD inliner tends to do more harm than
good (which is probably the reason why it isn't enabled by default in
-O builds). I'll add a comment to the source.

This would be good. I really wondered if this was a real decision or not.

Definitely a real decision, years ago at least, the frontend messed up the AST pretty badly when inlining was enabled. Not sure how things are today, or if we just didn't understand Walter's AST at the time.

 

- Otherwise the -inline option of ldmd2 becomes a no-op.

It would become a no-op for higher optimization levels, just as it is now, no?

David

Kai

--
You received this message because you are subscribed to the Google Groups "LDC - the LLVM D compiler" group.
To post to this group, send email to ldc...@googlegroups.com.

To unsubscribe from this group, send email to ldc-dev+unsubscribe@googlegroups.com.