On 27.07.2017 14:34, Richard Biener wrote:
On Thu, Jul 27, 2017 at 2:29 PM, Georg-Johann Lay <a...@gjlay.de> wrote:
For some targets, the best place to put read-only lookup tables as
generated by -ftree-switch-conversion is not the generic address space
but some target specific address space.
This is the case for AVR, where for most devices .rodata must be
located in RAM.

Part #1 adds a new, optional target hook that queries the back-end
about the desired address space.  There is currently only one user:
tree-switch-conversion.c::build_one_array() which re-builds value_type
and array_type if the address space returned by the backend is not
the generic one.

Part #2 is the AVR part that implements the new hook and adds some
sugar around it.
Given that switch-conversion just creates a constant initializer doesn't AVR
benefit from handling those uniformly (at RTL expansion?).  Not sure but
I think it goes through the regular constant pool handling.

Richard.
avr doesn't use constant pools because they are not profitable for
several reasons.

Moreover, it's not sufficient to just patch the pool's section, you'd
also have to patch *all* accesses to also use the exact same address
space so that they use the correct instruction (LPM instead of LD).

Loop optimization, for example, may move addr-space pointers out of
loops and actually does this for some CSWTCH tables.  I didn't look
into pool handling, but don't expect it allows to consistently
patch all accesses in the aftermath.

*If* that's possible, then it should also be possible to patch vtables
and all of their accesses, aka.

https://gcc.gnu.org/PR43745

e.g. in a target-specific tree pass?

With vtables it's basically the same problem, you'd have to patch *all*
accesses to match the vtable's address-space.  c++ need not to expose
address-spaces to the application, handling address-spaces internally
would be sufficient.

Johann

Reply via email to