Richard Guenther wrote: > On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand <uweig...@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.weig...@de.ibm.com
