<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The price is paid in different ways, everywhere. All I can say for<br>
sure is that addressing based on TPIDR is going to be more expensive<br>
than without. Only benchmarks could quantify it.<br></blockquote><div><br></div><div>well, will need some experimenting, first need an 64bit arm board (not sure if qemu arm64 is fit enough)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> wouldn't it make sense to add such an addressing instruction at LLVM IR<br>
> level? I mean there were no similar requests?<br>
<br>
</span>It's not come up before, no. It's not the worst idea I've heard, but<br>
equally I'm not exactly convinced of the benefit yet. Either way, it<br>
won't happen unless someone implements it ("patches welcome" as the<br>
saying goes).<br></blockquote><div> </div><div>Tried to describe at least the projected benefit in my prev emails, though no idea how useful it will be for the hole industry,  precisely how useful others will find it. Personally I assume that the cost of addressing overhead is worth to pay to save a lot of memory especially in pointer intensive applications (is there any class of application that cannot be called like that?). I know that Oracle invested some money in pointer compression, javascript has also some tricks to embedd information in the redundant part of 64 bit pointers. I am sure behind the scenes there are lot of such hacks to reduce the space used by 64 bit pointers. Already described in my prev email, but maybe some other wording: such segmented addressing would use only 32 bit pointers (in extreme case 16 bit!!) and the virtual memory area would be split into segments (well, yes, back to segmented addressing of x86). Once having this mechanism, segments could be relocated, saved/loaded to disk, shared between processes, migrated to other processes etc. One could write some fast loadable in memory database engines on top of it that would both fit for 64 bit servers and phones.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> Another solution for my problem would be to carry around the segment address<br>
> as extra function parameter to all functions, but that would be a funny<br>
<br>
</span>That's not exactly a terrible idea (I believe GHC might do something<br>
morally similar). It allows the compiler to spill it if necessary<br>
unlike reserving a register absolutely (say before a<br>
performance-critical loop), but its omnipresence probably discourages<br>
the spilling.<br>
<br>
If nothing else, it sounds like a useful way to get yourself up and<br>
running without backend or OS support.<br></blockquote><div><br></div><div>Just that would be nicer to write C++ code (runtime for my language) without exposing this detail... Ideally C++ could be extended, but take this at the moment rather like an utopia, and introduce keyword shortp in front of pointer declarations. </div><div><br></div><div>class Class {};</div><div><br></div><div>class TheClass {</div><div>     shortp char *int;</div><div>     shortp Class *cls;</div><div>};</div><div><br></div><div>and any statement that would access such pointers, should be compiled to "segmented" addressing.</div><div>The compiler should forbid the allocation of such objects on the stack. Though this mechanism could be extended to stack if another register could be allocated for stack segment based addressing.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
> So I wonder if it is possible in a<br>
> LLVM pass to track back all pointers in the IR that were initialized with a<br>
> certain function (factory function) and change the addressing<br>
<br>
</span>This is the problem I believe is logically impossible without source<br>
help, and if you've got that you'd just as well emit different IR to<br>
begin with.<span><br></span></blockquote><div><br></div><div>will study more in depth the code emitter in clang...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> On x86-64, unless I call some library functions I have the guaranty that<br>
> nobody would change the values in the gs/fs registers.<br>
<br>
</span>You do? I thought both were reserved by Linux. I suppose if you hack<br>
the kernel and/or libc you could fix them.<br></blockquote><div><br></div><div> well, I am confused, thought GS would be the thread boy, but it seems that it is FS, and GS is not affected. Tried the following:</div><div><br></div><div><br></div><div> #define GS_RELATIVE __attribute__((address_space(256)))</div><div>int GS_RELATIVE *gsr;</div><div><div>int main(){</div><div>   int i = 12345;</div><div>   arch_prctl(ARCH_SET_GS, &i);</div><div>   gsr = 0;</div><div>   printf("our gs relative ... %d\n", *gsr);</div></div><div>}</div><div><br></div><div>then I created threads an so on and the value 1234 at gs:0 is printed correctly, so the kernel does not seem to change the value of fs. <br>But of course I should clarify this.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>>Is there a way to tell LLVM not to reserve a certain register?<br></span>I don't think I follow here. Reserving a register is possible in<br>
certain limited circumstances (though discouraged, at least by me).<br>
Unreserving a register isn't, as far as I'm aware.<br></blockquote><div><br></div><div>Well, if FS and GS are compromised by kernel, thought to force the IR to reserve one of the general registers to hold my segment value instead of passing it as parameter to each function. I understand that some LLVM passes may observe that the value is used often, but I still have some overhead to pass a 64 bit pointer to each function call. <br>But joggling with thread local storage (__thread) comes to my mind that this could be my best solution, to store my segment address as "__thread" data. Well, would not use directly the content of any registers (gs/fs), but the generated machine code would load it in register any time I need it and would optimize it for several successive references. Though the question arises if there is a way to tell to the optimizer, hey, don't care, nobody will change the value of this so you can consider it "valid" after function calls as well, so no need for an eventual reload of the value from the thread local storage. </div><div><br></div><div>thanks a lot for your help<br>mph</div></div>
</div></div>