search for: subclassdata

Hello devs, Recently I've been working on a bug that can probably be fixed with the addition of a simple flag to a class descendant of `llvm::Value`. Without increasing the size of the class, I can just add this flag to `llvm::Value::SubclassData`. But this is not an easy task! This is because the offsetes/sizes of the data stored in the `SubclassData`, are hardcoded literals/enums. If you change but a single bit in one of those offsets/sizes in a base class, then all the classes derived, will have to be adjusted accordingly - which can be...

...e: > >> Hello devs, >> >> Recently I've been working on a bug that can probably be fixed with the >> addition of a simple flag to a class descendant of `llvm::Value`. >> Without increasing the size of the class, I can just add this flag to >> `llvm::Value::SubclassData`. But this is not an easy task! >> >> This is because the offsetes/sizes of the data stored in the >> `SubclassData`, are hardcoded literals/enums. >> If you change but a single bit in one of those offsets/sizes in a base >> class, then all the classes derived, will ha...

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added an...

hi,everyone. i notice that theres a subclassdata field in SDNode class but it seems that there no any method to access subclassdata, so i want to encode some information into it in my backend, and going to add the access function for it. is the way using it like this subclassdata recommanded? or the subclassdata is designed to use for other purp...

...red to MachineInstr). For example, on x86 lots of opcodes have *lock* variants. Right now, these are separate instructions. I'd prefer to make it into a target specific flag that can be toggled by some sort of post-isel action routine. One way to handle this might be to expand the use of SubclassData. There are 15 bits to play with and only the bottom 6-7 are in use (if I am reading it right). We can also reduce the width of following field NodeId (do we need 32-bit for it?) and widen SubclassData. Also, NumOperands and NumValues can be changed to take up fewer bits. I don't think...

Hi, I see this in the Type class: unsigned getSubclassData() const { return SubclassData; } void setSubclassData(unsigned val) { SubclassData = val; // Ensure we don't have any accidental truncation. assert(getSubclassData() == val && "Subclass data too large for field"); } How will the assert ever get triggered? The type is &...

...ach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode | + -> StoreSDNode...

...by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | +...

...by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | +...

...by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | +...

...ach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode | + -> StoreSDNode...

...86 lots of > opcodes have *lock* variants. Right now, these are separate > instructions. I'd prefer to make it into a target specific flag that > can be toggled by some sort of post-isel action routine. That's a good idea. > One way to handle this might be to expand the use of SubclassData. > There are 15 bits to play with and only the bottom 6-7 are in use (if > I am reading it right). We can also reduce the width of following > field NodeId (do we need 32-bit for it?) and widen SubclassData. Yep. See my response to Dan. I don't know how many target-specific flags yo...

...M/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | + -> StoreSD...

On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote: > Hi Chris, > > Would it be better to split add into multiple opcodes instead of using > SubclassData bits? No, I don't think so. The big difference here is that (like type) "opcode" never changes for an instruction once it is created. I expect that optimizations would want to play with these (e.g. convert them to 'undefined' when it can prove overflow never happens)...

On Feb 8, 2009, at 11:33 AM, Chris Lattner wrote: > > On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote: > >> Hi Chris, >> >> Would it be better to split add into multiple opcodes instead of >> using >> SubclassData bits? > > No, I don't think so. The big difference here is that (like type) > "opcode" never changes for an instruction once it is created. I > expect that optimizations would want to play with these (e.g. convert > them to 'undefined' when it can prove overfl...

On Jul 31, 2009, at 11:26 AM, David Greene wrote: > Right now the MemSDNode keeps a volatile bit in the SubclassData to > mark > volatile memory operations. > > We have some changes we'd like to push back that adds a NonTemporal > flag > to MemSDNode to mark instructions where movnt (on x86) and other > goodness > can happen (we'll also add the TableGen patterns to properly s...

...me applications value storage more than anything, many applications value compilation time very highly. getIntrinsicID is called all over the place (isIntrinsic uses it as well), and every single time it checks the function name. To me that sounds a lot more dramatic than 2 bytes. Anyway, using SubclassData could work. It's already being used for the calling convention, which has values ranging from 0 to 68 (fitting in 7 bits), while intrinsic ID's would take 9 bits. So that would only just work. However, the calling convention enums could be reordered to only take 3 bits. I was wondering...

...mporal > flag is significant. It's not fundamentally different from the > volatile flag in this respect. Ok, this sounds right, but this look wrong: /// Abstact virtual class for operations for memory operations class MemSDNode : public SDNode { [...] bool isVolatile() const { return (SubclassData >> 5) & 1; } Shouldn't that be MMO->isVolatile()? -Dave

...;> >> + a metadata 'targetflags' in LLVM atomic IR to pass this >> target-specific memory model hint >> >> + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints >> This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode >> >> here is the current SDNode class hierarchy of memory related nodes >> >> SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode >> |...

Ehud, can you elaborate on which classes you're trying to change. I know some of the classes already use methods like getSubclassDataFromInstruction() to hide bits from the subclasses. They could probably shift the data too. ~Craig On Fri, Dec 27, 2019 at 9:35 AM Bruno Ricci via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 26/12/2019 20:53, Ehud Katz via llvm-dev wrote: > > I've tested i...