Re: [patch] Fix PR tree-optimization/49771

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Richard Guenther wrote:

> > Btw, as pseudos do not have a single def site how can the above
> > ever be correct in the face of coalescing?

I had always understood this to reflect the simple fact that a
pointer to some type must never hold a value that is not properly
aligned for that type.  (Maybe this is only true on STRICT_ALIGNMENT
targets?)   This has always been an important property to generate
good code on SPU ...

> > For example on trees we can have
> >
> >  p_1 = &a; // align 256
> >  p_2 = p_1 + 4; // align 32
> >
> > but we'll coalesce the thing and thus would have to use the weaker
> > alignment of both SSA names.  expand_one_register_var expands
> > the decl, not the SSA name, so using get_pointer_alignment on
> > the decl would probably be fine, though also pointless as it always
> > will return 8.
> >
> > At least I don't see any code that would prevent a temporary variable
> > of type int * of being coalesced with a temporary variable of type vector
> > int *.

I don't really understand the coalesce code, but in the above sample,
the two variables must have the same type, otherwise there'd have to
be a cast somewhere.  Does coalesce eliminate casts?

> > Why should REGNO_POINTER_ALIGN be interesting to anyone?
> > Proper alignment information is (should be) attached to every
> > MEM already.
> 
> nonzero_bits1 seems to be the only consumer of REGNO_POINTER_ALIGN
> apart from maybe alpha.c and spu.c.
> 
> We should simply kill REGNO_POINTER_ALIGN IMHO.

On the SPU at least, REGNO_POINTER_ALIGN carries additional information
over just the MEM alignment.  Say, I'm getting a MEM the form
(mem (plus (reg X) (reg Y))), and the MEM is aligned to 32 bits.

This means I need to generate a rotate to fix up the value that was
loaded by the (forced aligned) load instruction.  However, the form
of this rotate can be simpler if I know that e.g. reg X is always
guaranteed to be 128-bits aligned and only reg Y introduces the
potential misalignment.  If on the other hand neither of the base
registers is guaranteed to be 128-bit aligned, I need to generate
more complex rotate code ...

I understand this may also be important on other platforms, e.g.
to choose which register to use as base and which as index in a
memory operation ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com