On 03/16/2012 01:55 PM, Richard Guenther wrote: > On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt <ber...@codesourcery.com> > wrote: >> >> The machine is "special". Pointer addition is a different operation than >> integer addition. It'll also need a new ptr_plus rtx code which takes a >> Pmode and an SImode operand. Pmode is larger than SImode but fits in a >> single register; intptr_t (which is what we'd need to use if we freely >> cast between pointers and integers is DImode - that requires two regs >> and can't be used for memory addressing. > > Hm, I see. On RTL would you get away with using REG_POINTER and > paradoxical subregs for the offset operand? Sth like (add (reg:DI > ptr) (subreg:DI (reg:SI off)))?
No, because (reg:DI ptr) is the wrong representation. Pointers only take a single reg, and besides such subreg games would be extremely nasty. There's also the problem that this really isn't an arithmetic plus, since the top bits of the pointer are unaffected. Hence it doesn't commute: lea is a different operation than add. There is no other arithmetic that operates on Pmode, so it is impossible to use that mode for integer types. Well, not impossible - I have existence proof in the form of the port I inherited - but you have to lie pretty heavily to the compiler to even just make it limp along. > Basically your issue on trees is that pointer information is lost and (wide) > integer operations appear? That's the main issue, yes. > Note that IVOPTs at the moment does not try to generate lea-style > pointer arithmetic while it could use &TARGET_MEM_REF for this. > We still assume that those addresses are within the object of > operand zero (but if you use a literal zero as that operand and put > the base somewhere else you might use that as a vehicle for > telling GCC the arithmetic is not within C language scope). Oh, ok. So IIUC maybe I can simply adjust the patch to still create POINTER_PLUS_EXPR in memory addresses, but use &TARGET_MEM_REF for the arithmetic in initializing the ivs? Bernd
