On Fri, Mar 16, 2012 at 2:05 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: > 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.
Hmm, ok. So to have your lea represented on RTL you cannot use a fancy pattern using add because it would not be an add. Hmm. If it merely does not affect upper bits then (set (reg:SI ptr) (add (reg:SI ptr) (reg:SI off)) might work (if Pmode aka DImode is word_mode of course - otherwise the upper bits would be lost ...). Or of course an UNSPEC generated during address legitimization. Do we even have sth like address legitimization for pointer arithmetic? I suppose we should, when expanding POINTER_PLUS_EXPRs. Maybe simply dispatching through a two-mode optab for expanding POINTER_PLUS_EXPRs would suit you? >> 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? Yes, that could work. Though it might end up being incredibly ugly ;) Richard. > > Bernd
