Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] proposal to simplify isel/asmprinter interaction with globals"
2009 Jun 22
0
[LLVMdev] proposal to simplify isel/asmprinter interaction with globals
On Jun 20, 2009, at 7:30 PM, Chris Lattner wrote:
>
>
> My proposed fix for this is to add an 'unsigned char' slot to
> MachineOperand that holds a target-specific 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
2010 Oct 10
1
[LLVMdev] More questions about non_lazy_ptr
I have a problem where my LLVM-generated code works on Linux but not on OS
X, and the problem involves non_lazy_ptr.
I have an external symbol named "@gc_safepoint_map", which is generated by
the linker's GCStrategy plugin. Since it is not generated until link time, I
declared it as an external symbol so that the modules that use it can
compile without error.
Here's what the
2010 Aug 24
1
[LLVMdev] non_lazy_ptr question
So, I've got a case where I am attempting to pass the address of a static
symbol from a module written in Tart (the language I am working on), to a
module written in C (which is part of Tart's runtime library). This works
fine on Linux, but fails on OS X because the address being passed is the
"non_lazy_ptr" symbol, not the symbol itself.
In my .bc file, I've got code that
2011 Oct 18
1
[LLVMdev] Building LLVM on PPC
Please don't be alarmed by the failed compiles on llvm-ppc-darwin. They are likely not your fault.
I'm trying to get a PPC build bot setup (arxan_bellini), and so far it's dying here:
Linking CXX shared library ../../lib/libgtest.dylib
Undefined symbols:
"vtable for llvm::raw_ostream", referenced from:
__ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest.cc.o
2008 Feb 05
0
[LLVMdev] Advice on implementing fast per-thread data
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
2009 Jun 16
4
[LLVMdev] PIC documentation ?
Anton,
>> Can I ask what platform ABI's are documented other than Itanium ?
> I'd bet all platform ABI are more or less documented.
Right.
Maybe we should collect references and do some LLVM PIC documentation and
put it on LLVM website ?
>> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF
>> and MachO backends.
> ABI is normally induced
2007 Sep 11
2
[LLVMdev] RFC: Darwin EH Patch
Hello, Bill.
> It's not exactly tweaking magic knobs. It's doing something that's
> already done -- putting the information in the TAI object, and
> allowing the specific back-end to set the appropriate strings.
It seems to me, that simple strings / bools there are not enough :)
"$non_lazy_ptr" emission is already in asm printers (in 2 places!). The
2008 May 17
1
[LLVMdev] Assembling the output of llc
Here's a more specific question about compiling native code: When I use
llc to generate a .s file, and then I try to assemble it using 'as', I
get tons of errors - it appears to be choking on lines like the following:
movl
L"_tart.core.Iterable<tart.core.String>:type"$non_lazy_ptr, %eax
The error I get is:
2008 May 19
1
[LLVMdev] Assembling the output of llc
On May 18, 2008, at 11:51 PM, Talin wrote:
> Anton Korobeynikov wrote:
>> Hello Talin,
>>
>>> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I
>>> assumed that it would choose sensible defaults...
>>>
>> Could you please provide a .bc testcase? There can be multiple
>> issues,
>> but at the first glance it
2008 Feb 05
2
[LLVMdev] Advice on implementing fast per-thread data
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
2013 Mar 07
2
[LLVMdev] ARM assembler's syntax in clang
Hi Ashi,
> ld: illegal text-relocation to _data_table in table.o from foo in
> use_table.o for architecture armv7
It looks like you're using iOS. I'm not familiar with the exact
workings of that platform, but I think a similar message would occur
in ELF-land.
If iOS *is* comparable, your issue is that symbols in dynamically
loaded objects can't (usually) be referenced directly
2009 Jan 02
2
[LLVMdev] link problem with llvm-pass
Hi,
I tried to implement an 'llc'-like tool in my project to manage
different passes and a target machine.
I use given llvm project structure to avoid problems but I have a link
problem and don't know how to solve it:
The target machine uses 'FindUsedTypes' pass and when I try to use my
target machine in the tool I got "Undefined symbols:
2007 Sep 11
0
[LLVMdev] RFC: Darwin EH Patch
Hi Anton,
>> It's not exactly tweaking magic knobs. It's doing something that's
>> already done -- putting the information in the TAI object, and
>> allowing the specific back-end to set the appropriate strings.
> It seems to me, that simple strings / bools there are not enough :)
> "$non_lazy_ptr" emission is already in asm printers (in 2 places!).
2012 Jun 14
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
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
2008 May 19
0
[LLVMdev] Assembling the output of llc
Anton Korobeynikov wrote:
> Hello Talin,
>
>> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I
>> assumed that it would choose sensible defaults...
>>
> Could you please provide a .bc testcase? There can be multiple issues,
> but at the first glance it seems, that names were not properly mangled.
>
I've created bug
2008 May 18
2
[LLVMdev] Assembling the output of llc
Hello Talin,
> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I
> assumed that it would choose sensible defaults...
Could you please provide a .bc testcase? There can be multiple issues,
but at the first glance it seems, that names were not properly mangled.
--
With best regards, Anton Korobeynikov.
Faculty of Mathematics & Mechanics, Saint Petersburg
2013 Mar 08
0
[LLVMdev] ARM assembler's syntax in clang
> And be warned that the PC doesn't point at the next instruction when you
use it like this - I believe you don't need to modify it at all if you swap
the pop and the .long.
Bernie, is it related to ARM pipeline? I'm interesting in this, is there
any other additional information?
On Fri, Mar 8, 2013 at 4:59 AM, Tim Northover <t.p.northover at gmail.com>wrote:
> Hi Ashi,
2009 Jan 04
0
[LLVMdev] link problem with llvm-pass
Dear Nico,
I believe you need to add LLVMipa to the list of libraries to link into
your tool. FindUsedTypes::ID is defined in lib/Analysis/IPA.
I think it would be LLVMipa.a if you added it to LLVMLIBS and ipa if you
added it to LINK_COMPONENTS.
-- John T.
Nico wrote:
> Hi,
>
> I tried to implement an 'llc'-like tool in my project to manage
> different passes and a
2012 Jun 14
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
> Right, that's a good point.
>
> On i386 Linux, the following 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
2013 Oct 01
2
[LLVMdev] JIT compiler on ARM issue
On 1 Oct 2013, at 14:49, Tim Northover <tnorthover at apple.com> wrote:
> We're hoping to get rid of the old one soon, but there are one or two features that don't quite work there yet. Lazy compilation is the only one I know of, since we got multi-module support yesterday. But there may be more.
Can MCJIT handle thread-local references? This was the feature keeping us on the