llvm dev - Aug 2009 - [LLVMdev] disabling combining load/stores in optimizer.

On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
>>
>> We are currently doing this, however I think disabling such
>> optimizations is a much better solution.
>
> An LLVM design goal is that backends should be able to outsmart
> instcombine when necessary, rather than having instcombine be able
> to disable parts of itself in order to avoid foiling the backends.
> Practicality sometimes steers elsewhere of course. Please explain
> why you think suppressing this particular optimization is better;
> it isn't obvious how it would look different in the end.
Yeah, I agree.  LegalizeTypes should be able to trivially lower this.

-Chris

On Monday 03 August 2009 18:01, Chris Lattner wrote:
> On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
> >> We are currently doing this, however I think disabling such
> >> optimizations is a much better solution.
> >
> > An LLVM design goal is that backends should be able to outsmart
> > instcombine when necessary, rather than having instcombine be able
> > to disable parts of itself in order to avoid foiling the backends.
> > Practicality sometimes steers elsewhere of course. Please explain
> > why you think suppressing this particular optimization is better;
> > it isn't obvious how it would look different in the end.
>
> Yeah, I agree.  LegalizeTypes should be able to trivially lower this.
"Should be" is the key clause here.  I agree with you and Dan in
general.
However, we have at least one testcase where the overhead of legalize is
so huge it takes *hours* to finish.  This is with LLVM 2.4 and I'm waiting
on an LLVM 2.5 upgrade to re-test so I can file a bug if necessary.

The point is that while legalize should be able to handle stuff, sometimes
it can't for other reasons.

                                  -Dave

On Mon, Aug 3, 2009 at 4:34 PM, David Greene<dag at cray.com>
wrote:
> On Monday 03 August 2009 18:01, Chris Lattner wrote:
>> On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
>> >> We are currently doing this, however I think disabling such
>> >> optimizations is a much better solution.
>> >
>> > An LLVM design goal is that backends should be able to outsmart
>> > instcombine when necessary, rather than having instcombine be able
>> > to disable parts of itself in order to avoid foiling the backends.
>> > Practicality sometimes steers elsewhere of course. Please explain
>> > why you think suppressing this particular optimization is better;
>> > it isn't obvious how it would look different in the end.
>>
>> Yeah, I agree.  LegalizeTypes should be able to trivially lower this.
>
> "Should be" is the key clause here.  I agree with you and Dan in
general.
> However, we have at least one testcase where the overhead of legalize is
> so huge it takes *hours* to finish.  This is with LLVM 2.4 and I'm
waiting
> on an LLVM 2.5 upgrade to re-test so I can file a bug if necessary.
That doesn't seem relevant; we shouldn't mess with transformation
passes to hide performance issues in CodeGen.

-Eli