similar to: [LLVMdev] (no subject)

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Bingo, thanks! Confirmed it works for both 32- and 64-bit targets. Should `sys::getProcessTriple()` be updated with this change? According to the documentation: /// getProcessTriple() - Return an appropriate target triple for generating /// code to be loaded into the current process, e.g. when using the JIT. I had to "-elf" to the result of this function for JIT to work on

I am currently setting up my Module with module->setTargetTriple(llvm::sys::getProcessTriple() #ifdef _WIN32 + "-elf" #endif ); And my ExecutionEngine with llvm::EngineBuilder(std::move(module)) .setErrorStr(&err) .setMCPU(llvm::sys::getHostCPUName())

getProcessTriple just determines operation system, and architecture. It doesn't deal with specific instruction set features. The CPU should be controlled by MCPU on the EngineBuilder i think. The CPU autodetection code lives in getHostCPUName in lib/Support/Host.cpp, but I don't think the JIT calls into. I think its expected the user would call it or pass a specific CPU string to the MCPU

As Yaron said, you need to add "-elf" to the end of your target triple to get MCJIT to generate ELF object in memory on Windows. This should work with 32- or 64-bit targets. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Joshua Klontz Sent: Monday, December 02, 2013 1:18 PM To: Dev Subject: [LLVMdev] MCJIT + Windows = Incompatible

Thank you. I'm letting it auto detect by setting the target using getProcessTarget. I disabled avx512 support by passing -avx512f (and the other variants) to setMAttrs on EngineBuilder. I can see refs to avx512 in X86.td. It's the exact same executable running on Kabylake. What does the Cannot select: specifically mean? Is there some table that doesn't have a definition for a key in

Hi everyone, I was happily using MCJIT for over a year until yesterday when I created a function call with an argument of a struct type. That caused a crash in SelectionDAG around DataLayout::getAlignment(). I remember the noise about the DataLayout started being mandatory. But I cannot find precise information. Should I set the DataLayout in every Module created? Where can I get the

Is the MCJIT infrastructure supported on Windows? I'm getting an "LLVM ERROR: Incompatible object format!" when running my project with both VS 2013 and Mingw_w64 (GCC 4.8.2). Looks like this issue has been brought up before [1,2] and the answer is "almost". Any help would be greatly appreciated. v/r, Josh [1]

I've been working at this for a few days now and I can't figure out what is broken. Google turns up similar issues from years back, but I hope this is a bug resurfacing. ACL entries are being deleted when files are saved. Here is an example: username: user1 group membership: Domain Users directory: /share/test file: test.xls getfacl /share # file: share # owner: DOMAIN+backupuser #

Hi, I am trying to implement a scenario similar to running ExceptionDemo.cpp with parameter -1 (where the JITed code calls the C++ function which throws an exception) Different from the given example I am using IRParser instead of IRBuilder. I can successfully catch the exception in Linux but the program crashes in Mac and Windows. The code is similar to as follows: ### The test.cpp :

Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was

Eric Christopher wrote: > On Wed, Jul 9, 2014 at 11:39 AM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> On 7/9/14, 12:33 PM, Eric Christopher wrote: >>> Any reason why you deleted code that isn't related? >>> >>> -eric >>> >>>> - enum SubArchType { >>>> - NoSubArch, >>>> -

With the following call: llvm::ExecutionEngine* engine; llvm::EngineBuilder builder( module ); builder.setEngineKind( llvm::EngineKind::Either ); // it will use JIT if available builder.setUseMCJIT ( true ); engine = builder.create(); These calls are successful in windows. But when I try in Linux (Ubuntu), the create() function fails with the error message: Target does not support MC emission

Hi edaqa, You might need to set your TargetOptions before calling selectTarget. E.g. builder.setTargetOptions(Opts).selectTarget(...); Or you could just let EngineBuilder call selectTarget for you (which is what the no-argument version of EngineBuilder::create does): llvm::ExecutionEngine * ee = builder. setErrorStr( &errStr ). setEngineKind( llvm::EngineKind::JIT ).

Hello, I'm using Mono with experimental LLVM backend support on PowerPC. I noticed that although LLVM's IR contains SIMD instructions the assembly produced doesn't contain any Altivec instructions and my PowerPC970 machine of course has Altivec support. Isn't there some kind of autodetection? I searched in Target sources but only found out that Altivec is disabled by default. Can

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.