search for: subclassoptionaldata

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 reduction. Should we give up on SubclassOptionalData > for F...

...mantically 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 likely one iota slower.. but it sure is easier to get the intent. B ? SubclassOptionalData |= BitToSet : SubclassOptionalData &= ~BitToSet; Otherwise looks good to me. Joe On Nov 15, 2012, at 5:50 PM, Joe Abbey <j...

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 to add in the future. Obvious downside is that it increa...

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' +

On Sun, Mar 17, 2019 at 1:47 PM Craig Topper <craig.topper at gmail.com> wrote: > Can we move HasValueHandle out of the byte used for SubClassOptionalData and move it to the flags at the bottom of value by shrinking NumUserOperands to 27? I like this approach because it is less work for me. :) But I agree with Sanjay below that this only kicks the can slightly further down the road (solutions (2) and (3) also have the same problem). Let's see...

...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 precedence… but the code is non-obvious: > > SubclassOptionalData = > (SubclassOptionalData & ~BitToSet) | (B * BitToSet); > This is an existing pattern that's used elsewhere in the file, so I had assumed it was well understood and preferred. > This is likely one iota slower.. but it sure is easier to get the intent. > > B ? SubclassOp...

I'm not aware of any additional bits needed. But putting us right at the edge leaves me uncomfortable. So an implementation that isn't limited by the 7 bits in SubclassOptionalData seems sensible. Thanks, -Warren From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Monday, October 2, 2017 12:06 AM To: Ristow, Warren Cc: Hal Finkel; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations Are we confident that...

...i?id=38086 https://bugs.llvm.org/show_bug.cgi?id=39535 https://reviews.llvm.org/D51701 ...so we need to make FMF changes regardless of FTZ. On Sun, Mar 17, 2019 at 2:47 PM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can we move HasValueHandle out of the byte used for SubClassOptionalData > and move it to the 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-...

...>> + bool any() { >> + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | >> + AllowReciprocal; >> + } >> > > Will do. > >> Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: >> >> SubclassOptionalData = >> (SubclassOptionalData & ~BitToSet) | (B * BitToSet); >> > > This is an existing pattern that's used elsewhere in the file, so I had assumed it was well understood and preferred. > >> This is likely one iota slower.. but it sure is easier to get the intent...

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

...@llvm.powi.f32(float %0, i32 %1) (gdb) (gdb) print *I $12 = {<llvm::Value> = { _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = 0x61035c0, UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 'D', HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', SubclassData = 0, NumOperands = 3, static MaximumAlignment = 536870912}, OperandList = 0x61b8e80} (gdb)

...M, 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 where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from here. > > Joe, what are the reasons for me to increment the IR version number? My understanding is that I'll just be using existing bits...

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

...nt *I > $12 = {<llvm::Value> = { > _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, > SubclassID = 68 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu &...

...lvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > I'm not aware of any additional bits needed. But putting us right > at the edge leaves me uncomfortable. So an implementation that > isn't limited by the 7 bits in SubclassOptionalData seems sensible. > > Thanks, > > -Warren > > *From:*Sanjay Patel [mailto:spatel at rotateright.com > <mailto:spatel at rotateright.com>] > *Sent:* Monday, October 2, 2017 12:06 AM > *To:* Ristow, Warren > *Cc:* Hal Finkel; llvm-dev at l...

...gt; (gdb) > (gdb) print *I > $12 = {<llvm::Value> = { > _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 > 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.e...

...nt *I >> $12 = {<llvm::Value> = { >> _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = >> 0x61035c0, >> UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 >> 'D', >> HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', >> SubclassData = 0, NumOperands = 3, static MaximumAlignment = >> 536870912}, >> OperandList = 0x61b8e80} >> (gdb) >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.e...

...n <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 where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from here. >> >> Joe, what are the reasons for me to increment the IR version number? My understanding is that I'll just be using exist...

...ions. Is it possible that the Value has been deleted from the program by GVN? Is this expected behaviour? This is the output when I type "print *V1" in gdb: {_vptr.Value = 0x91fa950, SubclassID = 92 '\\', HasValueHandle = 1 '\001', HasMetadata = 0 '\000', SubclassOptionalData = 31 '\037', SubclassData = 43368, VTy = {Ty = 0x921f6fc}, UseList = 0x8d5a550, Name = 0x8e06088} This is the output when I type "print *V1->getType()" in gdb: {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x92184c0}, ID = 72, Abstract = true, SubclassDat...

> It might be clearer, instead of using 'libm', to use something like 'trans' (for transcendental functions). That does seem clearer. ‘trans’ is definitely good with me. -Warren From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Tuesday, October 3, 2017 5:13 PM To: Ristow, Warren; Bruce Hoult Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a