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

Consider writes to a struct {i32 a; i32 b};

 

The optimizer can currently combine stores (i32, i32) to a single i64
store operation. Is there a way to disable that?

 

I feel that such optimizations may not result in any gain for PIC16 as
PIC16 does everything on i8.

 

 

 

- Sanjiv

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090802/41f01d14/attachment.html>

On Aug 2, 2009, at 11:08 PM, Sanjiv.Gupta at microchip.com wrote:

> Consider writes to a struct {i32 a; i32 b};
>
> 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.
> 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?

Dan

> > 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.