search for: relativel

...oglobal(), which has just become a noop. The correct code for this should be (I believe): _toglobal: ## @toglobal ## BB#0: pushq %rbp movq %rsp, %rbp lea %gs:(%rdi), %rax popq %rbp ret In the inlined version, the lea and movl should be combined into a single gs-relativel movl. Until we can generate correct code from IR containing address spaces, discussion of how to optimise this IR seems premature. David

On Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 03:52 AM, Pete Cooper wrote: >>> Why a backend should be responsible (meaning have knowledge) for a >>> mapping between high level address spaces and low level address spaces? >> Thats true. I’m thinking entirely from the persecutive of the backend >> doing

...rrect code for this should be (I believe): > > _toglobal: ## @toglobal > ## BB#0: > pushq %rbp > movq %rsp, %rbp > lea %gs:(%rdi), %rax > popq %rbp > ret > > In the inlined version, the lea and movl should be combined into a single gs-relativel movl. > > Until we can generate correct code from IR containing address spaces, discussion of how to optimise this IR seems premature. I've done a quick test: the problem is that the BITCAST node is not generated during the SelectionDAG building. If you look in SelectionDAGBuilder::vis...

...@toglobal >> ## BB#0: >> pushq %rbp >> movq %rsp, %rbp >> lea %gs:(%rdi), %rax >> popq %rbp >> ret >> >> In the inlined version, the lea and movl should be combined into a single >> gs-relativel movl. >> >> Until we can generate correct code from IR containing address spaces, >> discussion of how to optimise this IR seems premature. >> > > I've done a quick test: the problem is that the BITCAST node is not > generated during the SelectionDAG building. I...