Regimplification enhancements 1/3

[Richard Biener]

On Mon, Jun 16, 2014 at 1:45 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 06/16/2014 01:24 PM, Richard Biener wrote:
>>
>> On Mon, Jun 16, 2014 at 12:56 PM, Bernd Schmidt <bernds@codesourcery.com>
>> wrote:
>>>
>>> For the ptx port, I've needed to write a new pass which ensures all
>>> objects
>>> go into address spaces as required by the machine. This uses the
>>> regimplification code in gimplify-me.c, and that requires some fixes and
>>> upgrades.
>>
>>
>> Can you explain how and why you need re-gimplification here?  IMHO
>> you should apply the necessary steps yourself, not put in GENERIC
>> into GIMPLE and rely on the gimplifier.
>
>
> That's not actually what's happening - the pass modifies the address spaces
> of all objects (local & global vars etc.) and I have one additional patch in
> gimplify.c that recognizes address space mismatches on an ADDR_EXPR (also
> testing a new TYPE_QUAL_AS_IMPLICIT bit to ensure it only triggers in
> situations it's intended to) and inserts the necessary
> ADDR_SPACE_CONVERT_EXPR. With that I can pass all statements through
> regimplification to get a consistent view of the world again.

Uh.  So what do you do?  You'd place an object in a different address-space
and when seeing &foo then simply lie to GIMPLE and say the address
is really not in that address space?  What you you do when such
pointer is dereferenced then?

It looks wrong to me to do such semantic changing transforms in
gimplification.

Richard.

>> You can't turn a x = &foo; into x = (convert)&foo; this way abusing
>> the re-gimplification routines.
>> The re-gimplification routines do _not_ accept random GENERIC
>> operands.  They were written to handle registers becoming non-registers
>> and nothing more.
>
>
> It seems to work fine is all I can say. What it was written for and what it
> can be useful for are two different things.
>
>
> Bernd
>