search for: fmf

...Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over a...

Michael, Overall the code looks good. 80-cols: 2046 FMF.UnsafeAlgebra = 0 != (Record[OpNum] & (1 << bitc::FMF_UNSAFE_ALGEBRA)); 2047 FMF.NoNaNs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_NANS)); 2048 FMF.NoInfs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_INFS)); 2049 FMF.NoSi...

...Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over a...

We knew the day when we needed another FMF bit was coming back in: https://reviews.llvm.org/D39304 ...it was just a question of 'when'. :) I'm guessing that an FTZ bit won't be the last new bit needed if we consider permutations between strict FP and fast-math. Even without that, denormals-as-zero (DAZ) might also be useful...

...>>>>>> >>>>> >>>>> A function attribute would be a strict improvement over today: LLVM can’t do contraction today. But actually I’m not sure if it is the long term right choice: attributes don’t combine well with inlining for instance. You mentioned FMF earlier, why don’t we have a FMF to allow contraction? >>>> >>>> OK, I thought that the prerequisite for that was a fast-math pragma which I don’t think is something we have (I want to be able to specify contract=fast on smaller granularity than module). But now that I thi...

...would be a strict improvement over today: >>>>>>> LLVM can’t do contraction today. But actually I’m not sure if it >>>>>>> is the long term right choice: attributes don’t combine well >>>>>>> with inlining for instance. You mentioned FMF earlier, why don’t >>>>>>> we have a FMF to allow contraction? >>>>>> >>>>>> OK, I thought that the prerequisite for that was a fast-math >>>>>> pragma which I don’t think is something we have (I want to be >>>&g...

...t;>>>>>>> >>>>>>>>> A function attribute would be a strict improvement over today: LLVM can’t do contraction today. But actually I’m not sure if it is the long term right choice: attributes don’t combine well with inlining for instance. You mentioned FMF earlier, why don’t we have a FMF to allow contraction? >>>>>>>> >>>>>>>> OK, I thought that the prerequisite for that was a fast-math pragma which I don’t think is something we have (I want to be able to specify contract=fast on smaller granularity t...

...back. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > > > ... > > I think these are valuable problems to solve, but you should tackle them piece by piece: > > > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > > 2) the backend is still using the global UnsafeFPMath and it should be killed. > > I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). >...

...hich should fix this. >> >> Great! >> > > A function attribute would be a strict improvement over today: LLVM can’t do contraction today. But actually I’m not sure if it is the long term right choice: attributes don’t combine well with inlining for instance. You mentioned FMF earlier, why don’t we have a FMF to allow contraction? OK, I thought that the prerequisite for that was a fast-math pragma which I don’t think is something we have (I want to be able to specify contract=fast on smaller granularity than module). But now that I think more about, we should be able t...

...>>>> Great! >>>> >>> >>> A function attribute would be a strict improvement over today: LLVM can’t do contraction today. But actually I’m not sure if it is the long term right choice: attributes don’t combine well with inlining for instance. You mentioned FMF earlier, why don’t we have a FMF to allow contraction? >> >> OK, I thought that the prerequisite for that was a fast-math pragma which I don’t think is something we have (I want to be able to specify contract=fast on smaller granularity than module). But now that I think more about, w...

Another round of improved patches, and a patch for documentation changes to LangRef. * Make comments more up to date * Use 'arcp' instead of 'ar' * Use logical || Still based off of r168110 On Nov 15, 2012, at 3:31 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: >

Dear all, Can garch function fit also t-innovations or only Gaussian innovations? -- With kind regards -- Lepo pozdravljeni -- Gr??e (Gr?ezi) -- Gorazd Brumen ------------------------------- Mail 1: gbrumen at student.ethz.ch Mail 2: gorazd.brumen at fmf.uni-lj.si Tel.: +41 (0)1 63 34906 Homepage: valjhun.fmf.uni-lj.si/~brumen

...back. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > > > ... > > I think these are valuable problems to solve, but you should tackle them piece by piece: > > > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > > 2) the backend is still using the global UnsafeFPMath and it should be killed. > > I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). >...

Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +

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 other fastmath flags we'd want

...Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over a...

On 03/15/2017 12:10 PM, Adam Nemet via llvm-dev wrote: > Relevant to this discussion is > http://bugs.llvm.org/show_bug.cgi?id=25721 (-ffp-contract=fast does > not work with LTO). I am working on adding function attributes for > fp-contract=fast which should fix this. Great! > > Also now that we have backend optimization remarks, I am planning to > report missed

Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'):

...s no > instruction-level or function-level attribute/metadata for FMA-ness: > https://llvm.org/bugs/show_bug.cgi?id=25721 Interesting; we should at least have a function-attribute for this that Clang uses. Thanks again, Hal > To tie this back to the earlier thread about changes to IR FMF, the > possibility of adding FMA bits to FMF (as well as storing all FMF in > metadata) was discussed here: > https://llvm.org/bugs/show_bug.cgi?id=13118 > 3. The backend needs a thread of its own. We have at least these > mechanisms to handle FMA codegen: > a. TargetOptions for...

On 10/01/2017 06:05 PM, Sanjay Patel wrote: > Are we confident that we just need those 7 bits to represent all of > the relaxed FP states that we need/want to support? > > I'm asking because FMF in IR is currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can share the > struct with the backend's SDNodeFlags, but that already has one extra > bit for vector re...