similar to: [LLVMdev] Minor cosmetic issues

Hi Russell, I took care of these points except for > In -version output, > > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6svn > Optimized build. > Built Feb 14 2010(11:05:20). > > Registered Targets: > alpha - Alpha [experimental] > arm - ARM > bfin - Analog Devices Blackfin [experimental] > c - C

> I have installed LLVM on my machine (ubuntu) a while ago. I think my LLVM version is 2.8. is it supported in 2.8 ? When I install i didn't configure LLVM for mips. Do I have to configure it when I build ? I don't know what's the default llvm configuration for ubuntu! But you can check for mips support using "llc --version". Yes, it's supported in 2.8, although it

I have installed LLVM on my machine (ubuntu) a while ago. I think my LLVM version is 2.8. is it supported in 2.8 ? When I install i didn't configure LLVM for mips. Do I have to configure it when I build ? Thanks in advance. Really appreciate it. --- On Thu, 9/1/11, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: From: Bruno Cardoso Lopes <bruno.cardoso at gmail.com>

Ok. And what does llvm-gcc --version show? --- With best regards, Anton Korobeynikov On Mar 6, 2012 5:22 PM, "Rafael Parizi" <parizi.computacao at gmail.com> wrote: > > For compile and link Basicmath files (using shell script): > > llvm-gcc -emit-llvm basicmath_small.c -c -o basicmath_small.bc > llvm-gcc -emit-llvm cubic.c -c -o cubic.bc > llvm-gcc -emit-llvm

For compile and link Basicmath files (using shell script): llvm-gcc -emit-llvm basicmath_small.c -c -o basicmath_small.bc llvm-gcc -emit-llvm cubic.c -c -o cubic.bc llvm-gcc -emit-llvm isqrt.c -c -o isqrt.bc llvm-gcc -emit-llvm rad2deg.c -c -o rad2deg.bc llvm-link basicmath_small.bc cubic.bc isqrt.bc rad2deg.bc -o basicmath.bc

Hello, I was trying to compile a simple program with the CppBackend like so: $ clang str_arg.c -emit-llvm -S $ llc -march=cpp str_arg.ll It produces a file `str_arg.cpp` as expected, however it doesn't seem that the resulting file is correct. For once, it includes `<llvm/Analysis/Verifier.h>` which seems to have been moved to `llvm/IR/Verifier.h` as far back as 2013. My question is

Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a subdirectory like the rest of the other targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). Anton is planning to move MSP430 to use the same approach. Having all the targets use the same design simplifies the build system and keeps the target architecture more

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

I have gold from cvs, and llvm-gcc/llvm from svn. My platform is Ubuntu 9.04 x86_64. I've configured llvm-gcc with "--enable-multilib". When compiling the LTO example from http://llvm.org/docs/LinkTimeOptimization.html I have no problems with 64-bit compilation, but get the following with -m32. luked at node:~/tests/lto$ make USE32=1 llvm-gcc -m32 -c -o main.o main.c llvm-gcc

Yes, it's quite obviously dead and should be deleted. When I brought this up last time -- after realizing that it wasn't actually a backend that targetted c++ (which might be useful), but rather just something that emitted IR by calling llvm C++ functions (which really isn't IMO) -- someone also pointed out that it also really ought to be using IRBuilder...if anyone cared about it.

Hello. Excuse me. Why CMakeLists.txt from llvm-3.9.1.src does not contain WebAssembly target? So, it is like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ X86 XCore ) but not like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ Webassembly X86

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

> after realizing that it wasn't actually a backend that targetted c++ > (which might be useful) Exact same thing just happened to me.. it's not obvious, especially when reading the llc info: $ llc -version Registered Targets: arm - ARM arm64 - ARM64 (little endian) cpp - C++ backend x86 - 32-bit X86: Pentium-Pro and above x86-64

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

You've raised an important point here Pete, and while I disagree pretty strongly with it (regardless of whether Lanai makes sense or not), I'm glad that you've surfaced it where we can clearly look at the issue. The idea of "it really should have users outside of just the people who have access to the HW" I think is deeply problematic for the project as a whole. Where does

On Tue, Feb 9, 2016 at 11:01 PM, Pete Cooper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Feb 9, 2016, at 10:24 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > You've raised an important point here Pete, and while I disagree pretty > strongly with it (regardless of whether Lanai makes sense or not), I'm glad > that you've

Hi Roberto, The PIC24 family of devices share very little commonality with PIC16 beyond the naming convention. They're a register-based 16-bit architecture, unlike the PIC16. That said, that does mean that LLVM is a much more reasonable fit to target the PIC24 (and dsPIC) than it is for PIC16. Modeling your target files after the MSP430 or Blackfin backend is likely your best bet to get up

> Chris Lattner wrote: > >> Hi XCore and PIC16 maintainers, >> >> I'd appreciate it if you guys could move your AsmPrinter >> implementation to be in a subdirectory like the rest of the other >> targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). >> I've moved the XCore AsmPrinter in r79094:

*1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build directory, recursively, and all the output is what I pasted in last email (just the same to the that in source directory). Maybe the configure failed to do it. My command list for building the test suit is as followings:* *(1) cd ~/SRC_DIR/llvm/projects* *(2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk

Hi, I think this is a very ashamed question I have modified the version of the MSP430, after many problems it compiled, now I want to see is the changes generate what I want, but I don't know how for example with llc -march msp430 foo.ll -o newfoo.ll generates a file for the msp430 and actually did it. but I want to load my changes the --load option is supposed to do that, but the only new