similar to: Condition code in DAGCombiner::visitFADDForFMACombine?

On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has > no reassoc or contract fast math flag? By having the reassoc and contract flags on fadd, the frontend is

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

On 22.08.2018 17:52, Ryan Taylor wrote: > This is probably going to effect on other backends and break llvm-lit > for them? Very likely, yes. Can you take a look at how big the fallout is? This might give us a hint about what other frontends might expect, and who needs to be involved in the discussion (if one is needed). Cheers, Nicolai > > On Wed, Aug 22, 2018 at 11:41 AM

Maybe there is a cleaner solution but it seems like adding a 'nocontract' flag is close to the intention of spir-v and is an easy check in the DAGCombiner without breaking anything else and its intentions are very clear. Right now the DAGCombiner logic doesn't seem to be able to handle the case of having fast math globally with instruction level flags to turn off fast math. Right now,

Michael, >From the spec with regards to reassoc: – 15225 Include no re-association as a constraint required by the NoContraction Decoration. I don't see a solution given the situation where -fp-contract=fast and we want to contract. Furthermore, I think a 'nocontract' flag will allow the IR to be more readable in it's intention. The problem is you can have 2 fp arith

I don't think the global fast math flag should override the NoContraction decoration as that's mostly the point of that decoration to begin with, to have fine granular control while still having a broad sweeping optimization. Did I miss your point? I feel like I did. On Thu, Aug 23, 2018, 3:42 PM Michael Berg <michael_c_berg at apple.com> wrote: > Ryan, > > Given that the

Nicolai, Can you do without the use of -fp-contract=fast (Options.AllowFPOpFusion == FPOpFusion::Fast ) and without Unsafe? As I SPIR-V’s usage of NoContraction flies in the face of both. If so, you should be able to get what you want, as then you are down to just IR flags. You will need a model to generate the correct behavior though in your SPIR-V implementation wrt IR flag emissions.

There is no way to disable FMAs with 'fast' ops in LLVM. I would like to propose that LLVM's -fp-contract=off should disable fusion, regardless of any other flags since the Clang option suggests this to be the case: $ clang --help | grep fp-contract -ffp-contract=<value> Form fused FP ops (e.g. FMAs): fast (everywhere) | on (according to FP_CONTRACT pragma, default) | off

> On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Matt, > I'm sorry, actually it's fma not fmad. > > In the post-legalizer DAG combine for the given code it's producing fma not fmad. That doens't seem correct. > The contract is on the fadd. I’m not really sure what the rule is supposed to be for contract between the nodes.

For this code: %20 = fmul reassoc nnan arcp contract float %15, %19 %21 = fadd nnan arcp float %20, -1.000000e+00 This does not result in fused multiply-add. it seems like the logic to contact the fmul from the fadd is different than whether to decide to contract the fadd. I would think the logic would be the same for each instruction in the pair. On Tue, Aug 21, 2018 at 2:05 PM Ryan

> On Aug 21, 2018, at 23:06, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Why is isContractableFMUL different from isContractable? If contractable is only expected on the fmul, then what does it even mean to have it set on any other kind of instruction?

> On Aug 21, 2018, at 17:08, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has no reassoc or contract fast math flag? > > Thanks. fmad

Hal Finkel <hfinkel at anl.gov> writes: > There are a few conditions that contribute to the decision of whether > or not to make the fmuladd -> fma translation. The relevant code is in > CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: > > case Intrinsic::fmuladd: { > EVT VT = TLI.getValueType(I.getType()); > if (TM.Options.AllowFPOpFusion !=

On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <andrew.booker at arm.com>wrote: > The fmuladd intrinsic is described as saying that a multiply and > addition sequence can be fused into an fma instruction "if the code > generator determines that the fused expression would be legal and > efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic) > >

----- Original Message ----- > From: "Cameron McInally" <cameron.mcinally at nyu.edu> > To: "Andrew Booker" <andrew.booker at arm.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, January 11, 2013 12:37:07 PM > Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic > > > On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker < >

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

Sent from my Verizon Wireless 4G LTE DROID On Nov 17, 2016 5:53 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Nov 17, 2016, at 4:33 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Warren

----- Original Message ----- > From: "Sanjay Patel" <spatel at rotateright.com> > To: "Hal J. Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, > "andrew kaylor" <andrew.kaylor at

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this