Re: Preserve pointer types in ivopts

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Mar 16, 2012 at 2:05 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 03/16/2012 01:55 PM, Richard Guenther wrote:
>> On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt <bernds@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