similar to: [LLVMdev] Distribution in assembler format

I don't think I quite understand this... suppose for example you're trying to use an LLVM-based toolchain running on an x86 PC to write code for a device that uses an ARM processor in big endian mode, so you tell the LLVM code generator "generate code for ARM, big endian"... are you saying the optimizer will actually assume the target device is little endian because the

Hello Russell, Major pitfall #1: LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. I've been looking forward to the day that LLVM can be used for cross-architecture

Hi again, My point is that your code could not be written in C++ at this time because the only complete compiler for C++ is LLVM-GCC. It will do little endian optimizations on your x86 box and make the resultant bitcode file not work on the ARM processor. It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. Also the FAQ also

Russell Wallace wrote: > One issue I've been looking at with regard to using LLVM as a compiler > backend is distribution of programs, particularly on Linux where > different distributions have different binary package formats and it > is usual to ship programs as source rather than binary; specifically, > I'm looking at the general case where the end user may not have (the

On Jan 29, 2010, at 12:09 PM, Samuel Crow wrote: > Hello Russell, > > Major pitfall #1: > LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been

On Wed, Mar 23, 2016 at 5:55 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > If you’re shipping binaries, statically link. That's a good question - should I ship binaries? I've picked up the idea that if you want a Linux program of a version that isn't included in your distro packages, you build from source, but it seems here that including a binary in the

I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a 64-bit Windows 7 system. I tried it with the 32-bit compiler as a test case first and that appeared to work, then with the 64-bit compiler in the hope that would give me a 64-bit build of LLVM, but instead got this error message: [ 86%] Generating X86CompilationCallback_Win64.obj Microsoft (R) Macro Assembler (x64)

... Or maybe not? I just tried it again in the exact same configuration that did work before, and this time it fails at an earlier stage with a different error: [ 66%] Building CXX object lib/Target/Mips/CMakeFiles/LLVMMipsCodeGen.dir/Mips16FrameLowering.cpp.obj Mips16FrameLowering.cpp NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~2.0\VC\bin\cl.exe' : return code '0xffffffff'

When you say 'configuring and installing an appropriate version of LLVM and its libraries yourself' - that is indeed what I did on my own machine (Ubuntu 14.04 apt-get thinks 3.4 is latest, so I'm currently building 3.8 from source) - but how would you recommend doing this on a user's machine? On Wed, Mar 23, 2016 at 5:17 PM, David Jones <djones at xtreme-eda.com> wrote:

Hello, Samuel Crow wrote: > It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. > Which ones llvm assembler instructions is not endian-agnostic? -- Ivan

After some running some more tests, a weird addendum to this case: the build also fails at the same place with the same error message if MinGW isn't in the path. I'm not talking about MinGW instead of Microsoft C++, it's just that the build works if and only if MinGW is in the path _as well as_ the 32-bit version of Microsoft C++. On Sat, Aug 24, 2013 at 8:15 PM, Russell Wallace

On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com> wrote: > Why do you say spin? You're dismissing all use-cases other than this very narrow one I'd (with my own spin) characterise as "Do What I Mean, I Can't Be Bothered To Get My Code Right". Fair enough, you're arguing in favour of a point; but it's not one I agree with. Tim.

Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < apilipenko at azulsystems.com> wrote: > Are you going to run some of the existing passes? Why can’t you just use > the returned change-made value from the passes? > > Artur > > > On 20 Dec 2015, at

On Sun, Feb 28, 2010 at 9:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace > <russell.wallace at gmail.com> wrote: >> What's the largest integer such that something like 'return ((a * b) / >> c) >> d' works correctly on all major platforms? > > Twice the size of a pointer, i.e. 64 bits on

Yes, that is what I was thinking. Should I report it as a bug? On Sun, Sep 20, 2015 at 2:31 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Russell Wallace" <russell.wallace at gmail.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> >

Ah! I don't know what GUARDSYM does or whether there is any way to turn it off at the compiler end; a Google search doesn't seem to find anything; but it would be great if you could add support for msvc 2015. When I try using clang as the compiler, I get a different error message. In this case it seems to be just not finding the standard libraries? C:\t>clang -c a.c C:\t>lld

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

On Wed, Jul 1, 2015 at 12:22 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > I am arguing in favor of a point, and I understand you disagree with it, > but I don't think I'm dismissing any use cases except a very small > performance increment. > I'm sure Google has numbers about how much electricity/server cost they save for X% performance improvement.

Generally it is safer to include ISO headers first (using the ‘#include <...>’ form) so as to minimise the possibility that a later user declaration or macro definition interferes with the correctness of the Standard libraries. It also tends to make pre-compiled header implementations faster and more shareable across a larger set of files. I would like to suggest revising the LLVM

For what it's worth we did a similar thing, but overrode RTDyldMemoryManager directly This allowed us to control where the RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use small memory model and avoid the mov rax, xxxxxxx; call rax code generated for x86)*, and also override findSymbol() to have the same behaviour as described in 4). --matt * later issues in not