On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > 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 ...
Hmm. I suppose we'd need to see at the initial expand stage that the move is going to be handled specially. For other strict-align targets we end up with store/load-bit-field for unaligned accesses, so I suppose SPU doesn't want to go down that path (via insv/extv)? > 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? ] Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose we'd need to pick a conservative REGNO_POINTER_ALIGN during expansion of the SSA name partition - iterate over all of them in the partition and pick the lowest alignment. Or even adjust the partitioning to avoid losing alignment information that way. I suppose the RTL code transforms are careful to update REGNO_POINTER_ALIGN conservatively. Richard. > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU Toolchain for Linux on System z and Cell BE > ulrich.weig...@de.ibm.com >
