similar to: [LLVMdev] Why do X86_32TargetMachine and X86_64TargetMachine classes exist?

On Mon, 2014-01-06 at 14:23 -0800, Jim Grosbach wrote: > Hi David, > > AFAIK, the answer is basically “because it’s always been that way.” I > seem to recall there were some things that were different (data layout > string and such), but that could also be parameterized if it hasn’t > been already by the recent refactorings, I suppose. It is *all* now parameterized. The classes

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

Thanks for your response Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it

Hola Aaron, Just having that code didn't work since the linker still stripped it out, so I have that function called from the code in the system that actually is being used by our app. Kinda grubby, but I include: #include "llvm/lib/Target/X86/X86TargetMachine.h" Which is in the LLVM lib, not the LLVM inc directory. This little maneuver made our Mac builds really unhappy, so

Hi folks, Not sure if this is the right mailing list target, but I'm trying out the new LLVM 7.0 packages found at http://apt.llvm.org by porting over an existing LLVM 6.0 project of ours to the new version. In doing so, I found that the executable always segfaulted at the same spot with no explanation: 0x0000000000fefe33 in

Just be aware that those ifdefs were recommitted and reverted several times, so I'm not sure what the state is. On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kern, > > We also had issues with mixing GCC/Clang builds when testing the 7.0 > release branch. > > My colleague submitted a patch that fixed the issue

Hi David! Thanks for reaching out, the codegen part of the tutorial is fine, but when I try to generate the object code file, it throws segfault. Also please note that I'm using release build of llvm, actually I don't know whether that is the root cause or not. I also run through valgrind, it seems like a invalid read from stack. |||Error Summary: | |1 errors in context 1 of 1:

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

> On Dec 23, 2014, at 9:45 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 22, 2014, at 2:56 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Circling back to Chandler on file size differences. Here are the highlights of what is different. >> >> For my analysis I built LLVM and Clang using a clang built with my

Hi, I'm developing a very basic new LLVM backend for a RISC machine (named Risco), based on the existing Sparc and Mips backends and the main tutorial [1]. I'm having trouble registering the backend so the main tools can see it. My project code is outside the source tree, and I've altered the Makefile to generate a shared library for the backend (libLLVMRiscoCodeGen.so). I've

Hi all :) I'm new to llvm! I'm going through the kaleidoscope : compiling llvm IR to object code tutorial, code in the listings breaks and causes a segmentation fault. After some investigation through gdb, probably this constructor call, causing the segfault. |Program received signal SIGSEGV, Segmentation fault.|| ||0x00000000004afee0 in

I built the LLVM 2.2 distribution under Visual Studio for x86-64 just fine, but then trying to run my first "hello world" application, found that the JIT compiler was not enabled. I'm completely new to LLVM, so I didn't know exactly where to look to see why the JIT for my platform wasn't being built (is it in the configure steps, or in the C++ code itself?). My educated guess

> On Dec 23, 2014, at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > >> On Dec 23, 2014, at 10:41 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote: >> >> On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>>> It should be

Circling back to Chandler on file size differences. Here are the highlights of what is different. For my analysis I built LLVM and Clang using a clang built with my patches. The same clang was used for the baseline and the stripped build. I used the following CMake command: cmake -G "Sublime Text 2 - Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=Yes

Hello all, I'm trying to bring an LLVM-based project that is working on Linux up on Win32. I am having problems with llvm::ExecutionEngine::create returning a NULL. I traced it to these lines: // Unless the interpreter was explicitly selected, try making a JIT. if (!ForceInterpreter && JITCtor) EE = JITCtor(MP, ErrorStr); // If we can't make a JIT, make an

Hi vedant, The program didn't pass the checking "OF->getArch() != Triple(Arch).getArch()" loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by "

Hi vedant, 1. The definition is from llvm/Supprot/ELF.h. But this machine information(e_machine) is given to compiler at lib/MC/ELFObjectWriter.cpp. I greped the whole llvm project and found that e_machine was assigned at only two files. One was lib/MC/ELFObjectWriter.cpp(there was an comment said “e_machine=target”) and the other was tools/obj2yaml/elf2yaml.cpp(GDB stopped only at the

Hi vedant, 1. First, I think your theory is right that llvm’s object file reading libraries do not “understand” the architecture I’m working on. Since I’m using binutils as assembler which means llvm can only provide asm and object file is provided by biutils. I think these ELF header information is provided by my binutils now, so maybe I have to modify binutils code to provide ELF header