On Thu, Jul 27, 2017 at 3:32 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > 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).
Sure. So then not handle it in constant pool handling but in expanding the initializers of global vars. I think the entry for this is varasm.c:assemble_variable - that sets DECL_RTL for the variable. > 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? Ah, ok. I see what you mean. Once the address of a global var is taken the pointers refering to it have to use the proper address-space. So yeah, it looks like this would need to be done in a (target specific) pass, probably an IPA pass in case the variables are used from multiple functions. > 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. The IPA pass should be able to handle this transparently (vtables are just global decls with initializers). Of course the question is whether the linker can handle relocations between address-spaces for example? As of the patch I think it is too specific (switch-conversion only) for my taste. What you can do I think is in assemble_variable handle the case of ! TREE_PUBLIC && ! TREE_ADDRESSABLE -- non-exported, non-address taken variables can be put into a different address-space transparently by adjusting their type to reflect the changed address-space. This should catch the switch-conversion case that didn't run into the loop case. It won't fix vtables I think because they are always exported unless you use LTO, they also end up address-taken I think. For vtables (a bigger chunk than switch-conversion decls) adjusting things in the C++ FE is probably a good idea if it helps AVR. Richard. > Johann
