On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > 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 ...
We do not preserve pointer type casts in the middle-end (anymore). >> > 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? No, there is no cast between different pointer types. Information is not attached to types but to real entities. >> > 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 ... Because then you need the value of X + Y instead of just picking either? Why not expand this explicitly when you still have the per-SSA name alignment information around? > 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 ... Well, we still have REG_POINTER. Richard. > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU Toolchain for Linux on System z and Cell BE > ulrich.weig...@de.ibm.com >