Re: [named address] ice-on-valid: in postreload.c:reload_cse_simplify_operands

[Georg-Johann Lay <avr@gjlay.de>]

Ulrich Weigand schrieb:
> Georg-Johann Lay wrote:
> 
>>http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
>>
>>Are you going to install that patch? Or maybe you already installed it?
> 
> No, it isn't approved yet (in fact, it isn't even posted for approval).
> Usually, patches that add new target macros, or new arguments to target
> macros, but do not actually add any *exploiter* of the new features,
> are frowned upon ...

I thought about implementing a "hidden" named AS first and not exposing 
it to user land, e.g. to be able to do optimizations like
    http://gcc.gnu.org/PR49857
    http://gcc.gnu.org/PR43745
which need named AS to express that some pointers/accesses are different.

The most prominent drawback of named AS at the moment is that AVR has 
few address registers and register allocation often regerates unpleasant 
code or even runs into spill fails.

The AS in question can only be accessed by means of post-increment 
addressing via one single hard register.

> Thus, I'd prefer to wait until you have patch ready that exploits this
> in the AVR backend, and then submit the whole series.
> 
>>Then, I wonder how the following named AS code translates:
>>
>>int a = *((__as int*) 1000);
>>
>>As const_int don't have a machmode (yet), I guess the above line just 
>>reads from generic AS and reading from a specific address from named AS 
>>cannot work.
> 
> This should work fine.  Address space processing doesn't really depend
> on the machine mode; the address space is annotated to the MEM RTX
> directly.  Code like the above ought to generate a MEM with either
> an immediate CONST_INT operand or one with the immediate loaded into
> a register, depending on what the target supports, but in either case
> the MEM_ADDR_SPACE will be set correctly.  It's then up the target to
> implement the access as appropriate.

Thanks for pointing this out. I just used the mmode in my implementation 
instead of MEM_ADDR_SPACE. My bad.

>>Moreover, INDEX_REG_CLASS, REGNO_OK_FOR_INDEX_P, HAVE_PRE_INCREMENT et 
>>al. and maybe others are AS-dependent.
> 
> I agree for INDEX_REG_CLASS and REGNO_OK_FOR_INDEX_P.  In fact, I'd
> suggest they should first be converted to look similar to base registers
> (i.e. add MODE_CODE_INDEX_REG_CLASS and REGNO_MODE_CODE_OK_FOR_INDEX_P)
> and then add address space support to those extended macros, so as to
> avoid having to change lots of back-ends.   Do you need this for AVR?
> I could add that to the patch I posted previously ...

No, that's not needed for AVR.  I just noticed it.

> Now for HAVE_PRE_INCREMENT, I don't think we need anything special.
> This is used just as a short-cut to bypass pre-increment handling
> completely on targets that don't support it at all.  On targets
> that *do*, there will always be additional requirement on just
> which memory accesses support pre-increment.  Therefore, the
> middle-end will still always check the target's legitimate_address
> callback to ensure any particular pre-incremented memory access
> is actually valid.  This mechanism can already look at the address
> space to make its decision ...

Thanks for all your explanations. Johann

> Bye,
> Ulrich