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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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 ...

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.

> 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 ...

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 ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com