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
