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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > 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 ...
> 
> We do not preserve pointer type casts in the middle-end (anymore).

Huh, OK.  I was not aware of that ...

> >> nonzero_bits1 seems to be the only consumer of REGNO_POINTER_ALIGN
> >> apart from maybe alpha.c and spu.c.

There's also a use in find_reloads_subreg_address, as well as in the
i386/predicates.md and arm/arm.md files.

> > 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 ...
> 
> Because then you need the value of X + Y instead of just picking either?

Yes, exactly.

> Why not expand this explicitly when you still have the per-SSA name
> alignment information around?

When would that be?  The expansion does happen in the initial expand
stage, but I'm getting called from the middle-end via emit_move_insn etc.
which already provides me with a MEM ...

Can I use REG_ATTRS->decl to get at the register's DECL and use
get_pointer_alignment on that?  [ On the other hand, don't we have
the same problems with reliability of REG_ATTRS that we have with
REGNO_POINTER_ALIGN, given e.g. the coalescing you mentioned? ]

Bye,
Ulrich

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