search for: fastmath

...bit trickier with fast-math; for example, suppose two expressions are > equivalent, but *only* with reassociativity allowed? This isn't too different from "sext(a + b) == sext(a) + sext(b) only if the addition is nsw". However, it wasn't clear to me from the lang-ref what the fastmath flags really mean. What is the semantics of a program that computes ((a +fast b) +fast c) when ((a + b) + c) != (a + (b + c))? Does it have UB (in which case we can't hoist fastmath arithmetic) or is it more like poison? Depending on the answer, for fastmath we can considering doing what we...

...>>> are >>> equivalent, but *only* with reassociativity allowed? >> >> This isn't too different from "sext(a + b) == sext(a) + sext(b) only >> if the addition is nsw". >> >> However, it wasn't clear to me from the lang-ref what the fastmath >> flags really mean. What is the semantics of a program that computes >> ((a +fast b) +fast c) when ((a + b) + c) != (a + (b + c))? > > This is often true, and it is neither UB nor poison. The user has given the compiler the freedom to choose whatever the compiler decides will...

...assembler that uses Pentium or Athlon fast calculation potentials (but with less checking of errors) like Willus proposes. I think at this point, it should be the user's choice. So, R should propose both and should allow to switch from one to the other easily. Any suggestion? (one idea: make a fastmath package that would provide faster, but less error-proof ^, exp(), cos(), sin(),... functions). Unfortunately, I am not fluent enough in C and assembler to do it myself. Best, Philippe Grosjean ...........]<(({?<...............<?}))><............................... ) ) ) ) ) ( ( (...

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

Hi, I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, but we've already used up the 7 bits available in Value::SubclassOptionalData (the "backing storage" for FPMathOperator::getFastMathFlags()). These are the possibilities I can think of: 1. Increase the size of FPMathOperator. This gives us some additional bits for FTZ and ot...

On 16 October 2014 09:34, Hal Finkel <hfinkel at anl.gov> wrote: > Interesting. Looks like the problem is in (219545, 219569]. Yes. > and given the magnitude of the change, I think that the trip-count changes are more likely. Good point. > Of course, all of these things are bug fixes :( -- So how do we follow-up on this? Correctness before performance. Always. I'll create

...he flags at the bottom of value by > shrinking NumUserOperands to 27? > > ~Craig > > > On Sat, Mar 16, 2019 at 12:51 PM Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, >> but we've already used up the 7 bits available in >> Value::SubclassOptionalData (the "backing storage" for >> FPMathOperator::getFastMathFlags()). These are the possibilities I >> can think of: >> >> 1. Increase the size of FPMathOperato...

...Let's see if we can agree on a more future proof solution. -- Sanjoy > > ~Craig > > > On Sat, Mar 16, 2019 at 12:51 PM Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, >> but we've already used up the 7 bits available in >> Value::SubclassOptionalData (the "backing storage" for >> FPMathOperator::getFastMathFlags()). These are the possibilities I >> can think of: >> >> 1. Increase the size of FPMathOperato...

Which exactly was the plan? Add a new, regular instruction? Add a new constrained math intrinsic? Both? Andrew Kaylor made a good point here: * As I said, all LLVM IR FP instructions are //assumed// to have no side effects. I'm not sure we want an instruction that goes beyond this to be //defined// as having no side effects. It adds a complication to the language and introduces

...uched on this in the Differential Review and on this thread. To > summarize: > > FNEG(X) is not really the same operation as FSUB(-0.0, X), although the > differences are admittedly subtle. I even went as far to say that any > xforms between the two operations should only occur under FastMath > conditions. If we follow those rules, I think emergence guarantees that we > don't have to worry about the side effects of FNEG (please correct me if > I've missed something). > > Extending on that, I suspect that we should not be canonicalizing FNEG(X) > as FSUB(-0.0, X...

...mal flag to be set if fpmath=neon/sse/etc on all FP instructions, and in the vectorizer, we just test for that flag (which should also be set by fast-math). The Darwin vs. Linux problem is, then, moved to the target transform info, only setting the flag on ARM if... isDarwin OR ARMISA >= v8 OR fastMath OR fpMath == NEON Makes sense? cheers, --renato

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

...gBankSelect: Assign virtual register with size to virtual register with Register Bank. - Select: Translate the remaining (G) MachineInstr to MachineIntr. ** Implications ** As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs: - Need to remember FastMath flags for each MachineInstr. - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, etc. - Extend the MachineRegisterInfo to support size as well as register classes for virtual registers. I have sketched the changes in the attached patches to help picturing how the changes w...

...obalISel. That being said, I think we should push as much thing as possible in tablegen when we are done with prototyping. > > > ** Implications ** > > As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs: > - Need to remember FastMath flags for each MachineInstr. > > Not orthogonal to this proposal? I don't mind lumping it in as being able to do this is probably a good goal for the prototype at least, but it seems like being able to do this is something that could be done incrementally as a separate project? That’s a...

On 30.11.18 11:49, Heiko Becker via llvm-dev wrote: > --Resending my last mail, as it might have gotten lost -- > > Thanks Nicolai and Steve for the initial replies. > > So if I understand correctly there are 2 places you can pinpoint at > where distributivity is used: > > - simplification of infinity/NaN expressions > > - combination with FMA introduction Well

Constant propagation pass generates constant expression when undef is used in float instructions instead of propagating the undef value. ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: %add = fadd fast float undef, 2.000000e+00 ret float %add } Becomes: ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: ret float fadd (float undef, float 2.000000e+00) } Is it safe

...h size to virtual register with Register Bank. > - Select: Translate the remaining (G) MachineInstr to MachineIntr. > > > > ** Implications ** > > As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs: > - Need to remember FastMath flags for each MachineInstr. > - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, etc. > - Extend the MachineRegisterInfo to support size as well as register classes for virtual registers. > > I have sketched the changes in the attached patches to help picturi...

...h size to virtual register with Register Bank. > - Select: Translate the remaining (G) MachineInstr to MachineIntr. > > > > ** Implications ** > > As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs: > - Need to remember FastMath flags for each MachineInstr. > - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, etc. > - Extend the MachineRegisterInfo to support size as well as register classes for virtual registers. > > I have sketched the changes in the attached patches to help picturi...

...to virtual register > with Register Bank. > - Select: Translate the remaining (G) MachineInstr to MachineIntr. > > > > ** Implications ** > > As part of the bring-up of the prototype, we need to extend some of the > core MachineInstr-level APIs: > - Need to remember FastMath flags for each MachineInstr. > - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, > etc. > - Extend the MachineRegisterInfo to support size as well as register > classes for virtual registers. > > I have sketched the changes in the attached patches to hel...

...h size to virtual register with Register Bank. > - Select: Translate the remaining (G) MachineInstr to MachineIntr. > > > > ** Implications ** > > As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs: > - Need to remember FastMath flags for each MachineInstr. > - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, etc. > - Extend the MachineRegisterInfo to support size as well as register classes for virtual registers. > > I have sketched the changes in the attached patches to help picturi...