search for: getsubclassdatafrominstruction

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 it on MSVC, gcc,...

...espace=ignore-most - Example of rewrite: https://reviews.llvm.org/D81662 *CONTEXT* There are places in LLVM where we need to pack typed fields into opaque values. For instance, the `XXXInst` classes in `llvm/include/llvm/IR/Instructions.h` that extract information from `Value::SubclassData` via `getSubclassDataFromInstruction()`. The bit twiddling is done manually: this impairs readability and prevent consistent handling of out of range values (e.g. https://github.com/llvm/llvm-project/blob/435b458ad0a4630e6126246a6865748104ccad06/llvm/include/llvm/IR/Instructions.h#L564 ). More importantly, the bit pattern is scattered...

...662 >> >> *CONTEXT* >> There are places in LLVM where we need to pack typed fields into opaque >> values. >> >> For instance, the `XXXInst` classes in >> `llvm/include/llvm/IR/Instructions.h` that extract information from >> `Value::SubclassData` via `getSubclassDataFromInstruction()`. >> The bit twiddling is done manually: this impairs readability and prevent >> consistent handling of out of range values (e.g. >> https://github.com/llvm/llvm-project/blob/435b458ad0a4630e6126246a6865748104ccad06/llvm/include/llvm/IR/Instructions.h#L564 >> ). >> M...

...ing "large enough". (this is not ideal and it would be better to have a well-defined limit which could then be used to trigger an error instead of just overflowing, that's on my TODO list...) [4] > > I think the table speaks for itself. > > Craig, regarding the `getSubclassDataFromInstruction()`, it still does not turn the tides of the table, above, into the current implementation. > Cheers! [1] https://github.com/llvm/llvm-project/blob/master/clang/include/clang/AST/Stmt.h#L1088 [2] https://github.com/llvm/llvm-project/blob/master/clang/include/clang/AST/Stmt.h#L471 [3] https://gi...

I've tested it on MSVC, gcc, clang and icc. The solution in clang (in Decl.h) is not ideal (as you have said yourself). The solution I offer, is using a union of fields of class BitField (this is a new class that implements a bitfield of a specific type requested). With this, the definition, of the required bitfields in the subclass data, remains in the hands of the actual class needing them.

.../// Set the ordering constraint on this cmpxchg. - void setOrdering(AtomicOrdering Ordering) { + void setSuccessOrdering(AtomicOrdering Ordering) { assert(Ordering != NotAtomic && "CmpXchg instructions can only be atomic."); - setInstructionSubclassData((getSubclassDataFromInstruction() & 3) | + setInstructionSubclassData((getSubclassDataFromInstruction() & ~0x1c) | (Ordering << 2)); } + void setFailureOrdering(AtomicOrdering Ordering) { + assert(Ordering != NotAtomic && + "CmpXchg instructions can...