similar to: [LLVMdev] Assembling the output of llc

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Assembling the output of llc"

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 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
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 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
2009 Jun 21
4
[LLVMdev] proposal to simplify isel/asmprinter interaction with globals
Hi All, I'm working on various cleanups and simplifications to the 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
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 May 13
2
[LLVMdev] Difficulty compiling LLVM-based tools with clang
I recently modified my compiler's build files to use clang if it detects its available, however I'm running into a number of problems with this. I'm having one set of problems on OS X, and a different set of problems under Ubuntu. In both cases I'm attempting to link my frontend - compiled with clang - against the LLVM libraries - compiled with gcc. (I thought about compiling LLVM
2020 Nov 10
1
Fwd: Select output section for a function based on a subtarget feature
Hello, I'm implementing a port of LLVM for PowerPC VLE. It's a compressed instruction set similar to mips16 and ARM Thumb. Instruction encoding (VLE/non-vle) is selected for a given memory region by an attribute in a memory area descriptor. Targets supporting this that I know of are all bare-metal (so powerpc-none-elf). I'm trying to implement ELF support right now. VLE ELF files
2010 Jan 27
0
[LLVMdev] llc generated assembly does not work with gcc 3.4.4
Anton, This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for mingw or cygwin. Does it make sense to remove the "Windows" target and have "i686-pc-win32" just be a synonym for mingw? -Chris On Jan 27, 2010, at 1:32 AM, herz wrote: > The ll file: > > ; ModuleID
2008 Jun 06
0
[LLVMdev] [patch] add support for PIC on linux x86-64
On Jun 6, 2008, at 11:55 AM, Dan Gohman wrote: > On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: >> 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: >>> Hello, Rafael >>> >>> Awesome! But... -ENOPATCH :( >> >> Attached now. > > Hi Rafael, > > Thanks a lot for working on this! > > I have one question about the
2008 Jun 06
2
[LLVMdev] [patch] add support for PIC on linux x86-64
On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: > 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: > > Hello, Rafael > > > > Awesome! But... -ENOPATCH :( > > Attached now. Hi Rafael, Thanks a lot for working on this! I have one question about the patch; why did you choose too add a new enum, PICCallStyle, instead of reusing (possibly with some
2015 Apr 09
2
[LLVMdev] MMX/SSE subtarget feature in IR
Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file
2017 Aug 22
2
Subtarget Initialization in <ARCH>TargetMachine constructor
Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,
2013 Dec 03
0
[LLVMdev] [RFC] CGContext skeleton implementation
On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen
2017 Oct 17
2
getCacheSize() / subtarget machine id
Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some
2018 Apr 10
1
64 bit mask in x86vshuffle instruction
Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT,
2013 Dec 05
4
[LLVMdev] [RFC] CGContext skeleton implementation
On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, > attached is patch which implements a pretty minimal skeleton of a CGContext > implementation.
2016 Feb 21
2
Schedule pass for a subtarget?
[resending to correct llvm-dev address] Hi, I’d like to start enabling the loop data prefetch pass for Cyclone (an ARM64 subtarget). AFAICT, you can’t really add passes specifically to a subtarget but only to a target. This makes sense because in the new world, you could have different subtargets per function. I just want to make sure my understanding is correct. My plan is to add the pass
2019 Mar 13
2
Per-function subtargets
I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is