similar to: RFC: Refactor SubclassData

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.

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

Hi, Do you have some code we can look at (even if it is in a nasty unpolished state, just mark it WIP and put it on Phab) ? It is hard to evaluate an alternative without the code. That said I think that the table is a little bit one-sided. I have added some inline comments. On 30/12/2019 11:53, Ehud Katz wrote: > The solution in Clang is still very complicated and error prone. A lot of

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 purpose? thanks very much. --ether

I also want a way to add target specific flag to a SDNode (which should be transferred 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.

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 another flag to the MemSDNode

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 "unsigned" so how can

Here is the patch 0004-Enable-HLE-code-generation.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To

Here is the patch 0002-Add-HLE-target-feature.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To support

Here is the patch 0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and

Hi All, I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for

Hi Michael, Why do you want to add transactional memory support to LLVM ? Can't you implement transactional memory using a library call ? Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM. Thanks, Nadav On Feb 19, 2013, at 11:52 AM, Michael Liao <michael.liao at intel.com> wrote:

Hi All, I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for

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

On Sunday 02 August 2009 20:57, Evan Cheng wrote: > I also want a way to add target specific flag to a SDNode (which > should be transferred 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.

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

Hi Chris, Function is currently 108 bytes large. Could 4 more bytes really be an issue? Actually 2 should suffice. While I understand that some 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

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

On Thursday 11 February 2010 14:44:23 Dan Gohman wrote: > > Then we can't use it to hold a non-temporal flag. The operand might be > > non-temporal in one context but it may not be in another. > > Sharing only happens when two instructions have the "same" memory > reference info. You just need to make sure that the non-temporal > flag is significant.

On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote: > Hi all, > > While profiling I discovered that the Function::getIntrinsicID() > method is called a lot, and every time it uses string comparison to > recompute the ID number. As far as I know the name of an intrinsic > function doesn’t change, so the ID could be determined just once at > Function construction time.