Re: [patch] Fix powerpc 64 alignment problem for lwa instruction

[Andrew Pinski <pinskia at physics dot uc dot edu>]

> > The reason why I said this patch is incorrect is because the  
> > following:
> > #pragma pack(push, 2)
> > struct FixedRectangle {
> >   int left;
> >   int top;
> >   int right;
> >   int bottom;
> > };
> > #pragma pack(pop)
> >
> > long getLeft (struct FixedRectangle *a)
> > {
> >   return ((struct FixedRectangle*)(((char*)a)+4))->top;
> > }
> >
> > Compile at -Os -m64, we should still get a lwa
> 
> I don't agree.  The original object is (can be) misaligned, however  
> you access it.
> (You can't always tell that, e.g. if you put the cast in the caller  
> instead of the
> callee, but here you can.)

The alignment of the object is not the issue,  Look at the ISA for this
instruction.  It does not talk about the alignment of the load, just
the offset must be a mutliple of 4.  The reason why we fail is because
we don't know if the lo(a-b) is going to be a multiple of 4 unless we know
the alignment.  If you look at my example, we have a load which is unaligned
but the offset is a multiple of 4 (in my example 8).  We can take into account
the alignment of the memory address if we get a lo_sum because we don't know if
what the value of the offset is going to be.

To sum up the problem:
lwa's offset has to be a multiple of 4.
We don't know if lo(a) is going to be a multiple of 4 if the alignment of the memory
  is 32bits (or higher).
We need to reject lo(a) in those cases but not cases where we know the offset is a multiple
 of 4 which is valid.

This is what my patch does and makes sure we keep still use lwa in the cases where the
offset is known to be a multiple of 4 but the alignment of the memory location is not 32bit
aligned.

Thanks,
Andrew Pinski