search for: ntpoff

...asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These are all "magic" things that the assembler uses (for example, it generates a reference to a global's GOT entry instead of to the global itself). The thing that is really frustrating to me is that the asmprinters need to reverse engineer what isel *meant* in o...

On Mon, 4 Feb 2008, Brian Hurt wrote: > Another possibility, and I'm not sure how to do this in LLVM, would be to > sacrifice a register to hold the pointer to the unique per-thread > structure. This would be worthwhile to me even on the register-starved > x86-32. I suppose I could also just add a "hidden" (compiler-added and > -maintained) argument to every function

...I've missed __thread- I was thinking of the clunky POSIX threads implementation. Playing around a little bit with this, I find that: static __thread int i; int foo(void) { i += 1; return i; } compiles to: foo: pushl %ebp movl %esp, %ebp movl %gs:i at NTPOFF, %eax addl $1, %eax movl %eax, %gs:i at NTPOFF popl %ebp ret So, other than the segment override, this is no different than accessing a global variable. Which means I don't have to give up a clock cycle on allocation speed for the common case (ac...

...owing code, > >  static __thread int x[100000]; >  int* get_x() { return x; } > > compiled with "clang -shared a.c -o a.so" won't be possible do dlopen. I get exactly the same result with gcc 4.7 with and without -ftls-model=global-dynamic: movq %gs:0, %eax addl $x at ntpoff, %eax > Rafael, I think your argument has been that if we're unsure if there > is any reason to strictly preserve the user's choice, we should just > let LLVM choose a better model (and not have to specify any difference > between the "default" and global-dynamic mode...

Hello- I'm looking to implement a new programming language using LLVM as a back-end. Generally it's looking very good, I only have one question. The language is going to be an ML-style language, similiar to Haskell or Ocaml, except explicitly multithreaded and (like Haskell but unlike Ocaml) purely functional. But this means that speed of allocation is essential- purely functional

On Tue, Jun 12, 2012 at 7:53 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> We're trying to figure out if there's a good reason for this, and if >> we want to mimic that behaviour in LLVM, or if we should just take the >> tls_model attribute as a starting point, and choose a better model if >> we can. > > On i386, non-PIC code can be used

...enum value. The code in > asmprinter would be reduced to: > > switch (theoperandenum) { > case X86::MO_Flag_non_lazy_ptr: > O << "$non_lazy_ptr"; > break; > case X86::MO_Flag_TLSGD: > O << "@TLSGD"; > break; > case X86::MO_Flag_NTPOFF: > O << "@NTPOFF"; > break; > > > etc. The possible set of suffixes and modifiers are all target- > specific, so the main code generator would just pass them through (as > it does now). > > Does anyone have any objections to this? Can you reorg Machi...

...nt x[100000]; >>  int* get_x() { return x; } >> >> compiled with "clang -shared a.c -o a.so" won't be possible do dlopen. > > I get exactly the same result with gcc 4.7 with and without > -ftls-model=global-dynamic: > > movq %gs:0, %eax > addl $x at ntpoff, %eax Thanks for bearing with me on this. I think it's important that we get it right. I could have sworn I tried with -ftls-model yesterday, but apparently I didn't. Seems it works differently than I assumed (I guess I should have learnt not too assume things by now). Sorry about that....