search for: targetoption

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule); builder.setOptLevel(CodeGenOpt::Aggressive); builder.setEngineKind(EngineKind::JIT); builder.setUseMCJIT(true); builder.setCodeModel(CodeModel::JITDefault);...

...at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: > Hi, > > Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? > > I tried to play with TargetOptions without any success… > > Here is the kind of code we use to allocate the JIT: > > EngineBuilder builder(fResult->fModule); > builder.setOptLevel(CodeGenOpt::Aggressive); > builder.setEngineKind(EngineKind::JIT); > builder.setUseMCJIT(true); > builder....

Hi all, we have several features in Mips that are dependent on target abi. A recent commit(r224492) introduced a new -target-abi option to TargetOptions struct that provides access to abi string. This info is stored in MCSubtarget class(ARMSubratget in this case) and distributed to other libraries. Unfortunately, for Mips we need this info in other classes that don't have access to MCSubtarget class, like MCAsmBackend and MCTargetStreamer and...

...assembler. Could you please review it and tell me your opinion? http://reviews.llvm.org/D6091 Thanks Vladimir ________________________________ From: Daniel Sanders Sent: Wednesday, January 28, 2015 8:59 PM To: Eric Christopher; Vladimir Medic; llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer? Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu&...

...tion can then get the ABI name from there and pass it down to createMipsELFObjectWriter(). From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 January 2015 00:00 To: Vladimir Medic; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer? You can't really get there from here is the short answer. You can possible get MCTargetOptions, but then you need to change all of the constructors and calls across all of the backends to do this. I fixed all of the things that are curr...

...etz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >> >> I tried to play with TargetOptions without any success… >> >> Here is the kind of code we use to allocate the JIT: >> >> EngineBuilder builder(fResult->fModule); >> builder.setOptLevel(CodeGenOpt::Aggressive); >> builder.setEngineKind(EngineKind::JIT); >> builder.setUseMCJI...

I'm running LLVM under threadsanitizer (http://code.google.com/p/data-race-test/) to find and remove races in a larger program that uses LLVM as a library. One of the things that I found is that the TargetOptions are all global; you could create a TargetMachine targeting ARM and X86 in two threads, but they both have to share the same FloatABIType setting. This is silly, and I plan to fix it by moving all the globals in TargetOptions into getters and setters on TargetMachine. This means that the TargetMac...

On Dec 1, 2011, at 5:09 PM, Nick Lewycky wrote: > I'm running LLVM under threadsanitizer > (http://code.google.com/p/data-race-test/) to find and remove races in > a larger program that uses LLVM as a library. One of the things that I > found is that the TargetOptions are all global; you could create a > TargetMachine targeting ARM and X86 in two threads, but they both have > to share the same FloatABIType setting. > > This is silly, and I plan to fix it by moving all the globals in > TargetOptions into getters and setters on TargetMachine. This...

...t; > On Dec 1, 2011, at 5:09 PM, Nick Lewycky wrote: > >> I'm running LLVM under threadsanitizer >> (http://code.google.com/p/data-race-test/) to find and remove races in >> a larger program that uses LLVM as a library. One of the things that I >> found is that the TargetOptions are all global; you could create a >> TargetMachine targeting ARM and X86 in two threads, but they both have >> to share the same FloatABIType setting. >> >> This is silly, and I plan to fix it by moving all the globals in >> TargetOptions into getters and setters on...

Hi all, A quick question: The current implementation of the "allow unsafe math" option is to specify it via the TargetOptions object. However, this prevents the target-independent optimizer from using it. Are there any opinions (ha!) on how this could be achieved in a nice clean manner which doesn't require using the TargetOptions object in the optimizer? -bw

...ineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName()); engineBuilder.setEngineKind(llvm::EngineKind::JIT); engineBuilder.setOptLevel(llvm::CodeGenOpt::Aggressive); engineBuilder.setErrorStr(&mcjit_error); llvm::TargetOptions targetOptions; targetOptions.AllowFPOpFusion = llvm::FPOpFusion::Fast; engineBuilder.setTargetOptions( targetOptions ); TargetMachine *targetMachine = engineBuilder.selectTarget(); assert(targetMachine && "failed to create target machine"); std::cout << t...

On Dec 1, 2011, at 5:23 PM, Nick Lewycky wrote: >> Instead of adding a bunch of instance variables (+ getters/setters) into TargetMachine, why not make TargetOptions be a class, and have TM contain an instance of it? > > That works too, it makes little difference to me. One reason is that > most references to these globals are inside classes that derive from > TargetMachine so I wouldn't need to touch those lines. The second > reason is tha...

...languageOptions.RTTI = 1; languageOptions.Bool = 1; languageOptions.CPlusPlus = 1; clang::FileSystemOptions fileSystemOptions; clang::FileManager fileManager(fileSystemOptions); clang::SourceManager sourceManager( *pDiagnosticsEngine, fileManager); clang::TargetOptions targetOptions; targetOptions.Triple = "x86_64-unknown-linux-gnu"; targetOptions.CPU = "x86-64"; clang::TargetInfo *pTargetInfo = clang::TargetInfo::CreateTargetInfo( *pDiagnosticsEngine, -------------- next part -------------- An HTML attachment was s...

...etz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >> >> I tried to play with TargetOptions without any success. >> >> Here is the kind of code we use to allocate the JIT: >> >> EngineBuilder builder(fResult->fModule); >> builder.setOptLevel(CodeGenOpt::Aggressive); >> builder.setEngineKind(EngineKind::JIT); >> builder.setUseMCJI...

Hi, we generally run our JIT with UnsafeFPMath enabled, but there are a few specific instances where a block of code needs to follow strict FPMath. Is there a way to temporarily override TargetOptions for a specific block of IR? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170628/b1c65733/attachment.html>

Hello, I am using Ubuntu 11.10 64-bit. Following the instructions on the VMKit website I grabbed llvm, clang, and vmkit via svn (and GNU Classpath via the link of the page). Compilation of llvm, clang and classpath went fine. I had problems compiling vmkit, which seem to be related to a TargetOptions being required as a parameter when creating a TargetMachine in LLVM. This led to a couple other places in VMKit's code that tried to reference some LLVM global variables that no longer exist (I assume because they were moved into TargetOptions). I attempted to make some minor fixes to get by...

Chris Lattner wrote: > On Dec 1, 2011, at 5:23 PM, Nick Lewycky wrote: >>> Instead of adding a bunch of instance variables (+ getters/setters) into TargetMachine, why not make TargetOptions be a class, and have TM contain an instance of it? >> >> That works too, it makes little difference to me. One reason is that >> most references to these globals are inside classes that derive from >> TargetMachine so I wouldn't need to touch those lines. The second &gt...

...too, and this code may break next time we add one). > clang::FileSystemOptions fileSystemOptions; > clang::FileManager fileManager(fileSystemOptions); > > clang::SourceManager sourceManager( > *pDiagnosticsEngine, > fileManager); > > > clang::TargetOptions targetOptions; > targetOptions.Triple = "x86_64-unknown-linux-gnu"; > targetOptions.CPU = "x86-64"; > > clang::TargetInfo *pTargetInfo = > clang::TargetInfo::CreateTargetInfo( > *pDiagnosticsEngine, **** > > ** ** > > _____...

To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and another with “unsafe-fp-math=false”, but this won’t work if we want to parallelize the backend in the future, which is something Eric mentioned in his talk last...

...return 1; case ' ': break; case '0': OLvl = CodeGenOpt::None; break; case '1': OLvl = CodeGenOpt::Less; break; case '2': OLvl = CodeGenOpt::Default; break; case '3': OLvl = CodeGenOpt::Aggressive; break; } TargetOptions targetopts = InitTargetOptionsFromCodeGenFlags(); std::unique_ptr<TargetMachine> tmachine(moduletarget->createTargetMachine(moduletriple.getTriple(), cpuname, ftrlist, targetopts, Reloc::Default, CodeModel::Default, OLvl)); assert(tmachine && "Could not allo...