similar to: [LLVMdev] Enable changing UnsafeFPMath on a per-function basis

----- Original Message ----- > From: "Reid Kleckner" <rnk at google.com> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 12, 2015 2:54:48 PM > Subject: Re: [LLVMdev] Enable changing UnsafeFPMath on a per-function basis > > > > Whatever

I've been investigating what is needed to ensure command line options are passed to the backend codegen passes during LTO and enable compiling different functions in a module with different command line options (see the links below for previous discussions). http://thread.gmane.org/gmane.comp.compilers.llvm.devel/78855 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80456 The command

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,

On Fri, Dec 5, 2014 at 2:40 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed Dec 03 2014 at 11:39:23 AM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> >>> >>> On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka

On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com>

Updated patch is attached. Note this is just a work-in-progress patch and I plan to address the feedback comments later if this patch is in the right direction. This is how the command line options are parsed and used by the backend passes: 1. Tools such as clang and llc call cl::ParseCommandLineOptions. Any of the options that should be written to the bitcode as function or module attributes

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);

CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions. I think a lot of configuration things these days tend to be done with function attributes in IR. You can just query the function attribute wherever without any need

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current

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:

Hello everyone, I'd like to propose the attached patch to form FMA intrinsics aggressively, but in order to do so I need some clarification on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below: UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically

I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is

On Thu, Jul 18, 2013 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

Hi All, I've gotten a few notes over the last few months and also given some of the recent changes to various backends to "update" the default tunings for a generic processor it made me think again about adding support for tuning to a processor rather than generating processor specific code - hence, mtune. I hope this is rather uncontroversial, but happy to discuss at length if

ARM backend emits different eabi build attributes based on the ISA variant the target supports or whether certain fast-math options are passed on the command line. For example, these are the attributes that have different values depending on whether -ffast-math is passed to clang: $ clang -target armv7-linux-gnueabi -ffast-math (with -ffast-math) .eabi_attribute 20, 2 @ Tag_ABI_FP_denormal

Hi all, When trying to generate a VFCmp instruction when UnsafeFPMath is set to true I get an assert "Unexpected CondCode" on my x86 system. This also happens with UnsafeFPMath set to false and using an unordered compare. Could someone look into this? While I'm at it, is there any reason why only the most significant bit of the return value of VFCmp is defined (according to

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Have you filed a bug? > > While I’m at it, is there

Hello everyone, I'm currently working on a project that required me to fundamentally modify certain mechanisms of the x86 backend, as well as certain functions within PrologEpilogInserter (so my changes are not confined to a single pass - e.g. they include changes to the x86RegisterInfo constructor). In my current solution, I have added an option within

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Please provide a testcase. > > While I’m at it, is

On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com> wrote: > >> Thanks for your feedback, Eric. >> >> I still think we may be talking past each other a little bit, but rather >> than >> > > Might be, sorry if so :( > > >> delving