similar to: [LLVMdev] [PATCH] fast-math patches!

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not

Trying to apply patches.. What's your base revision? Joe On Nov 15, 2012, at 5:44 PM, Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > >

Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is

On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Michael, > > The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely

On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. > > + bool any() { > + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | > + AllowReciprocal; > + } > Will do. > Gripe: This pattern is probably super fast and has

On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> Hi Michael, >> >> The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A'

Hi Michael, The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely need to be documented. Evan On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at

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: >

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.NoSignedZeros = 0 !=

On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal

On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > I think I missed what problem we're trying to solve here. > > I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing

I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all the other content. -------------- next part -------------- A non-text attachment was

On Oct 30, 2012, at 4:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and

I think I missed what problem we're trying to solve here. I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from

On Nov 14, 2012, at 5:13 PM, Michael Ilseman <milseman at apple.com> wrote: > I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all

On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at apple.com> wrote: > > This is similar to how gcc defines *-fno-signed-zeros:* > "Allow optimizations for floating point arithmetic that ignore the > signedness of zero. IEEE arithmetic specifies the behavior of distinct > +0.0 and -0.0 values, which then prohibits simplification of expressions > such as

On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback > from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and changed descriptions of remaining flags: > * Make 'N' and

Hi Micheal, On Mon, Oct 29, 2012 at 4:34 PM, Michael Ilseman <milseman at apple.com> wrote: > I > Flags > --- > no NaNs (N) > - ignore the existence of NaNs when convenient > no Infs (I) > - ignore the existence of Infs when convenient > no signed zeros (S) > - ignore the existence of negative zero when convenient > Does this mean ignore the possibility

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

On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > I think I missed what problem we're trying to solve here. > > I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing