Richard Guenther wrote: > On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > > 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)?
One issue here is that accesses aren't necessarily "unaligned" as far as the middle-end is concerned: in the current example, we in fact have an access to a 32-bit integer that is aligned on a 32-bit boundary (which is the default alignment for integers). It's just that even so, the address is not *128-bit* aligned, and all SPU load instructions require this level of alignment ... The other issue is that as Andrew mentioned, all this means that just about every single memory access needs to be handled this way, and attempts to have everying go through insv/extv in the past have resulted in less efficient code generation. > > 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. That would certainly be helpful. > I suppose the RTL code transforms are careful to update REGNO_POINTER_ALIGN > conservatively. They're supposed to, yes. In practice, REGNO_POINTER_ALIGN is mostly used for pseudos allocated to hold pointer types (reflecting the type's alignment requirement) and for virtual/hard registers pointing into the stack (stack, frame, virtual args, ...), reflecting the various ABI alignment guarantees about the stack. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
