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

> > The optimizer can currently combine stores (i32, i32) to a single
> > i64 store operation. Is there a way to disable that?
> 
> Not currently. There are some ideas floating around about
> including in TargetData a list of integer types that the
> target natively supports, which would allow instcombine
> and other passes to make more informed decisions, but
> at this point it's just ideas.
There are other cases that we can benefit from such ideas. Could you
please give pointer to these discussions?
> 
> > I feel that such optimizations may not result in any gain for PIC16
> > as PIC16 does everything on i8.
> 
> The legalize pass should turn an i64 store into 8 i8 stores
> then, which is essentially the same as what an {i32,i32} store
> would turn into. Is there a problem with this?
> 
We are currently doing this, however I think disabling such
optimizations is a much better solution.

On Aug 3, 2009, at 1:20 PM, Alireza.Moshtaghi at microchip.com wrote:
>>> The optimizer can currently combine stores (i32, i32) to a single
>>> i64 store operation. Is there a way to disable that?
>>
>> Not currently. There are some ideas floating around about
>> including in TargetData a list of integer types that the
>> target natively supports, which would allow instcombine
>> and other passes to make more informed decisions, but
>> at this point it's just ideas.
>
> There are other cases that we can benefit from such ideas. Could you
> please give pointer to these discussions?
See "Adding legal integer sizes to TargetData" on Feb 1, 2009 on  
llvmdev.

-Chris

On Aug 3, 2009, at 1:20 PM, Alireza.Moshtaghi at microchip.com
wrote:
>>
>>> I feel that such optimizations may not result in any gain for PIC16
>>>
>>> as PIC16 does everything on i8.
>>>
>>
>>
>> The legalize pass should turn an i64 store into 8 i8 stores
>>
>> then, which is essentially the same as what an {i32,i32} store
>>
>> would turn into. Is there a problem with this?
>>
>>
>>
>
> 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.

Dan

On Mon, Aug 3, 2009 at 3:09 PM, Dan Gohman<gohman at apple.com>
wrote:
>
> On Aug 3, 2009, at 1:20 PM, Alireza.Moshtaghi at microchip.com wrote:
>>>
>>>> I feel that such optimizations may not result in any gain for
PIC16
>>>>
>>>> as PIC16 does everything on i8.
>>>>
>>>
>>>
>>> The legalize pass should turn an i64 store into 8 i8 stores
>>>
>>> then, which is essentially the same as what an {i32,i32} store
>>>
>>> would turn into. Is there a problem with this?
>>>
>>>
>>>
>>
>> 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.
Perhaps the transformation in question is actually memcpy->scalar
load+store?  For a target where the scalar takes more than a couple
registers, if the backend can't disambiguate the pointers, it's
essentially forced to copy src->stack temporary->dest.  For an 64-bit
memcpy on a target with 8-bit registers, I imagine the result is quite
ugly.

-Eli

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

> > 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.
> 
Well, for one thing, our port has no native operation other than 8-bit
so it does not make sense to promote operations to higher precisions.
Eventually all those operations will be lowered and the resulting code
is most likely worse than if it was not promoted in the first place. So
I think it should be at the discretion of port to enable or disable such
optimizations as needed.

A