On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: > On 03/16/2012 11:08 AM, Richard Guenther wrote: >> >> Your patch as-is is not safe at the moment. But why is casting a pointer >> to an integer prohibitly expensive? That fact should be an implementation >> detail of GIMPLE. Or is it the issue that IVOPTs chooses an integer >> type that does not necessarily match the mode we'll use on RTL? >> (thus, ptr_mode vs. Pmode issues, and/or sizeof (sizetype) != sizeof (void *) >> issues?) > > 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)))? Or even use a plain sign/zero_extend which is what expansion would generate at the moment I think. I suppose the HW either sign- or zero-extends that offset operand anyway. Basically your issue on trees is that pointer information is lost and (wide) integer operations appear? 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). Richard.
