search for: operandsneeddelet

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

...ow many target-specific flags you need, but we should be able to carve out four more bits from SubclassData without changing anything else. > Also, NumOperands and NumValues can be changed to take up fewer bits. > I don't think we need 16-bits for each. Probably true. > So NodeType, OperandsNeedDelete, SubclassData, NodeId, NumOperands, > and NumValues together are using 96 bits (assuming int is 32-bit and > short is 16-bit). I think there is opportunity here to re-pack them > and find quite a few bits for target specific data. I agree. If you and Dan agree, I'll take a crack at...

...leisNonTemporal, but that's just a detail :-). My biggest concern is how this is encoded in the SDNode. It'd be good to avoid making MemSDNode bigger, but there are a variety of ways that exiting bits can be made available. NodeType doesn't need all 16 of its bits, for example, and OperandsNeedDelete could be merged with OperandList with a PointerIntPair if needed. How are you representing movnt in LLVM IR, with an intrinsic? Dan

...nly 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 we need 16-bits for each. So NodeType, OperandsNeedDelete, SubclassData, NodeId, NumOperands, and NumValues together are using 96 bits (assuming int is 32-bit and short is 16-bit). I think there is opportunity here to re-pack them and find quite a few bits for target specific data. Evan On Jul 31, 2009, at 11:26 AM, David Greene wrote: > Righ...

...ere's a pipe there. :) > My biggest concern is how this is encoded in the SDNode. It'd be > good to avoid making MemSDNode bigger, but there are a variety of ways > that exiting bits can be made available. NodeType doesn't need all 16 > of > its bits, for example, and OperandsNeedDelete could be merged with > OperandList with a PointerIntPair if needed. *shudder* Undefined behavior? No thanks. Right now, the lower five bits of SubclassData are used to encode various things for memory SDNodes. One of those is the volatile bit. This leaves 10 bits for alignment information...

...iggest concern is how this is encoded in the SDNode. It'd be >> good to avoid making MemSDNode bigger, but there are a variety of >> ways >> that exiting bits can be made available. NodeType doesn't need all >> 16 >> of >> its bits, for example, and OperandsNeedDelete could be merged with >> OperandList with a PointerIntPair if needed. > > *shudder* Undefined behavior? No thanks. What undefined behavior? Is it PointerIntPair that's making you shudder? That's implementation-defined behavior. Very different :-). And it's checked b...