similar to: [LLVMdev] Fast-math flags in constant expressions

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Fast-math flags in constant expressions"

2014 Dec 02
2
[LLVMdev] Fast-math flags in constant expressions
Out of curiosity, how would you envision fast-math flags interacting with constant expressions? Off the top of my head, I can’t think of any flags that would be relevant if the expression can just be constant-folded away at full precision anyways. > On Nov 28, 2014, at 4:56 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote: > > Doesn't look like a bug, more like a
2014 Sep 19
2
[LLVMdev] More careful treatment of floating point exceptions
Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey
2018 Aug 20
3
Condition code in DAGCombiner::visitFADDForFMACombine?
I'm curious why the condition to fuse is this: // Floating-point multiply-add with intermediate rounding. bool HasFMAD = (LegalOperations && TLI.isOperationLegal(ISD::FMAD, VT)); static bool isContractable(SDNode *N) { SDNodeFlags F = N->getFlags(); return F.hasAllowContract() || F.hasAllowReassociation(); } bool CanFuse = Options.UnsafeFPMath || isContractable(N); bool
2018 Aug 22
2
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
2018 Aug 22
4
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2018 Feb 28
5
how to simplify FP ops with an undef operand?
For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter
2018 Aug 21
2
Condition code in DAGCombiner::visitFADDForFMACombine?
> 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
2018 Aug 21
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2018 Feb 28
3
how to simplify FP ops with an undef operand?
Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to
2010 Nov 09
1
[LLVMdev] uninitialized value warnings: LLVMParser.cpp
These warnings started appearing recently when building LLVM: llvm[2]: Compiling LLParser.cpp for Release build /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp: In member function ‘bool llvm::LLParser::ParseBr(llvm::Instruction*&, llvm::LLParser::PerFunctionState&)’: /Volumes/Data/Users/kremenek/llvm/lib/AsmParser/LLParser.cpp:3195: warning: ‘Op1’ may be used uninitialized in
2018 Mar 01
0
how to simplify FP ops with an undef operand?
We can do "add %x, undef" => "undef" because for any value of %x, we can always find a value that when added to %x produces any value in the domain of integers. This is not the case with floats since with some inputs, e.g., NaNs, we are not able to produce some values in the domain (e.g., there's no value of %x that makes "fadd NaN, %x" return 42.0). In
2014 Sep 05
5
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as
2018 Feb 28
0
how to simplify FP ops with an undef operand?
I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems like a surprising result.  And I don't think we
2018 Aug 23
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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,
2016 Nov 20
3
uninitialized values in Attributes.cpp
I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)
2018 Aug 23
3
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2018 Aug 22
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2018 Aug 21
3
Condition code in DAGCombiner::visitFADDForFMACombine?
> 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.
2016 Nov 20
3
uninitialized values in Attributes.cpp
Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,
2018 Aug 23
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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