<div dir="ltr">> <span style="font-size:12.8px">Very nice if something that solves this issue for real could make it into tree.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'll keep you in the loop, thanks for the attached patch by the way.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div><div><span style="font-size:12.8px">Dylan</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 1:39 AM, Mikael Holmén <span dir="ltr"><<a href="mailto:mikael.holmen@ericsson.com" target="_blank">mikael.holmen@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We have an out-of-tree target that is also Harvard architecture, so we're interested in this as well.<br>
<br>
So far, we've "solved" the issue by extending the datalayout so we can specify our "function pointer address space" there and then add/use it when necessary. Our current patch for this is small but hacky (too hacky to be upstreamed), but it has done the job for us for quite some time.<br>
<br>
Very nice if something that solves this issue for real could make it into tree.<br>
<br>
Regards,<br>
Mikael<span class=""><br>
<br>
On 07/11/2017 07:54 AM, Dylan McKay via llvm-dev wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hello all, I’m looking into solving an AVR-specific issue and would love to hear peoples thoughts on how to best fix it.<br>
<br>
<br>
  Background<br>
<br>
As you may or may not know, I maintain the in-tree AVR backend, which also happens to be (to the best of my knowledge) the first in-tree backend for a Harvard architecture.<br>
<br>
In this architecture, code lives inside the ‘program memory’ space (numbered 1), whereas data lives inside RAM “data space”, which corresponds to the default address space 0. This is important because loads/stores use different instruction/pointer formats depending on the address space used, and so we need correct address space information available to the backend itself.<br>
<br>
Due to the fact that address spaces in LLVM default to 0, this means that all global or constant variables default to living inside data space. This causes a few issues, including the fact that the SimplifyCFG pass creates switch lookup tables, which default to data space, causing us to emit broken table lookups and also wasting precious RAM.<br>
<br>
<br>
  The problem - emitting pointers as operands<br>
<br></span>
*NOTE*: Feel free to skip to tl;dr of this section if you don’t care too much about the details<span class=""><br>
<br>
There are different instructions which require different fixups to be applied depending on whether pointers are located in data space or program space.<br>
<br>
Take the |ICALL| instruction - it performs an indirect call to the pointer stored in the |Z| register.<br>
<br>
We must first load the pointer into |Z| via the ‘ldi’ instruction. If the pointer is actually a pointer to a symbol, we need to emit a |AVR_LO8_LDI_GS| relocation, otherwise we emit a |AVR_LO8_LDI| relocation. There are a few other cases, but they’re irrelevant for this discussion.<br>
<br>
We can quite easily look at the |GlobalValue*| that corresponds to the pointer if it is a symbol and select the fixup based on that, but that assumes that the address spaces are always correct.<br>
<br>
Now, imagine that the pointer is actually a function pointer. LLVM does not expose any way to set address space in the IR for functions, but because it derived from GlobalValue, it does have an address space, and that address space defaults to zero. Because of this, every single function pointer in the AVR backend that gets loaded by the |ldi| will be associated with data space, and not program space, which it actually belongs to.<br>
<br></span>
*tl;dr* functions default to address space zero, even though they are in a different space on Harvard architectures, which causes silent codegen bugs when we rely on the address space of a global value<span class=""><br>
<br>
<br>
  Proposed solution<br>
<br>
It would be impossible to set the address space correctly on creation of |llvm::Function| objects because at that point in the pipeline, we do not know the target architecture.<br>
<br></span>
Because of this, I’d like to extend |TargetTransformInfo| with hooks that like |getSwitchTableAddressSpace()|<wbr>, |getFunctionAddressSpace()|. I have already got a WIP patch for this here <<a href="https://reviews.llvm.org/D34983" rel="noreferrer" target="_blank">https://reviews.llvm.org/D349<wbr>83</a>>.<span class=""><br>
<br>
Once we have that information available to TargetTransformInfo, I propose we add a pass (very early in the codegen pipeline) that sets the address space of all functions to whatever value is specified in the hooks.<br>
<br>
This works well because we don’t let frontends specify address space on functions, nor do we even mention that functions have address spaces in the language reference.<br>
<br>
The downside of it it is that you wouldn’t normally expect something like an address space to change midway through the compilation process. To counter that however, I doubt the pre-codegen code cares much about the value of function address spaces, if at all.<br>
<br>
On top of this, at the current point in time, |Pointer<Function>::getAddress<wbr>Space| is downright incorrect on any Harvard architecture, and for other architectures, the address space for functions will still stay the default of zero and will not change at all.<br>
<br>
Does anybody know anything I haven’t thought of? Any reasons why this solution is suboptimal?<br>
<br>
​<br>
<br>
<br></span><span class="">
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>