<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks again for your help!</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>>><br>
>> Probably fairly minimal in most cases (on x86). On ARM there is<br>
>> definitely a cost.<br>
>><br>
> hm... why? You cannot have indexed addressing?<br>
What I need is a way to force <br>
</span>The code that needs to be emitted is roughly:<br>
[..."segment"-offset into x1...]<br>
mrs x0, tpidr_el0<br>
ldr xD, [x0, x1]<br>
<br>
That's a more complex addressing mode and an additional MRS<br>
instruction over the usual sequence. You also lose the ability to fold<br>
the actual address-computation into the LDR.<br></blockquote><div><br></div><div>but this is the price you pay always for RISC vs. x86, or? Probably it is difficult to quantify but wonder if it would add more than 5% slowdown to an average program, especially long running server class application.</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><br>
> and now the obvious question: for aarch64, is there an adrspace(256)<br>
> identical declaration for LLVM?<br>
<br>
</span>Nope. That's what I meant by saying there's no direct control over<br>
these features from LLVM.<br></blockquote><div>wouldn't it make sense to add such an addressing instruction at LLVM IR level? I mean there were no similar requests? Do not know if there is any interest, but this would help implementing lot of stuff like pointer size compression on 64 bit (pointers would be kept as 32bit), easier data sharing between processes (mmap with segmented addressing), position independent data (load and save chunks of data with pointers, keeping pointers semantics valid).</div><div><br>Knowing this, it means that my compiler has to generate platform dependent assembler code inside the IR. Which means I would not be able to run such a code inside LLVM virtual machine. </div><div><br></div><div>Another solution for my problem would be to carry around the segment address as extra function parameter to all functions, but that would be a funny </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><br></span>It's a very difficult problem. The main issue is that the stack won't<br>
be in this special address space (at least not without heavy LLVM<br>
modifications), so you need a way to distinguish stack accesses from<br>
heap. Without source annotation that's reducible to the halting<br>
problem. For example:<br>
<br>
int load_address(int *addr) {<br>
return addr;<br>
}<br>
<br>
int evil(int *heap_addr) {<br>
int local_var = 42;<br>
return load_address(rand() % 2 ? heap_addr : &local_var);<br>
}<br></blockquote><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"><br>
Should the code emitted for load_address use gs or not?<br></blockquote><div><br></div><div>the stack should not be in this address space and this addressing should not apply to stack. The framework would make any kind of C++ constructor private (friend accessible only to some Factory methods), so such objects could not be created on the stack only on heap. So I wonder if it is possible in a LLVM pass to track back all pointers in the IR that were initialized with a certain function (factory function) and change the addressing</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Tried to play with a naiv approach. </div><div class="gmail_extra"><br></div><div class="gmail_extra">uint8_t *global_segment; </div><div class="gmail_extra">#define ainline __attribute__((always_inline)) </div><div class="gmail_extra">template<class A> </div><div class="gmail_extra"> class CompactPointer </div><div class="gmail_extra"> { </div><div class="gmail_extra"> uint32_t adr; </div><div class="gmail_extra"> public: </div><div class="gmail_extra"> ainline A *operator->() { return reinterpret_cast<A*>(static_cast<uint32_t*>(global_segment)+adr);} </div><div class="gmail_extra"> }; </div><div class="gmail_extra"><br></div><div><div><br></div></div><div><div>int main() { </div><div> CompactPointer<OtherObject> cpoo; </div><div> CompactPointer<Object> cp = cpoo->cpo; </div><div>}</div><div>~ </div></div><div class="gmail_extra"><br></div><div class="gmail_extra">all such dereferencing statements would have in the IR references to the global_segment. Could track back all those (with a custom LLVM pass) and translate to a "segmented instruction". Having seen that address(256) is specific to X86, could generate for both x86-64 and Aarch64 custom addressing code. The problem is that doing so I would probably break the chance that some code get optimized in other phases, if I would apply such a pass at later stages, I might not be able to find the patterns. </div><div class="gmail_extra"><br></div><div class="gmail_extra">On x86-64, unless I call some library functions I have the guaranty that nobody would change the values in the gs/fs registers. Is there a way to tell LLVM not to reserve a certain register?<br><br>I wish more attention would be given to such a design pattern through all languages and platforms.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry if there is a bit of confusion in what I write, but I am still a bit confused as I do not know well yet LLVM and the platforms themselves, and would like to know what are my possibilities before starting to read hundreds of pages of documentation</div><div class="gmail_extra"><br></div><div class="gmail_extra">thanks in advance for the answers,</div><br><div>rgrds,<br>mobi phil<br><br>being mobile, but including technology<br><a href="http://mobiphil.com" target="_blank">http://mobiphil.com</a></div>
</div></div>