[LLVMdev] RFC: SDNode Flags
David Greene
dag at cray.com
Mon Aug 3 09:30:19 PDT 2009
On Saturday 01 August 2009 15:12, Dan Gohman wrote:
> LoadSDNode, which inherits from MemSDNode is the largest
> SDNode. With the current SDNode allocation strategy, making it
> bigger will increase the allocation needed for all nodes.
Ok.
> > new (N) LoadSDNode(..., isVolatile|isNonTemporal);
> >
> > Thoughts?
>
> This sounds reasonable. I'd suggest using names like MemRefFlags rather
> than isVolatileisNonTemporal, but that's just a detail :-).
There'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, meaning we can represent alignments up to
2^1024, which seems like a bit much. :)
What do you think about carving four more bits out of the alignment field
so we have five flag/semantic bits and can represent alignments up to 2^64?
That seems like plenty of alignment headroom.
> How are you representing movnt in LLVM IR, with an intrinsic?
Yes, it's an intrinsic inserted just before the load or store of interest.
I'm not particularly happy with this solution because I'm not sure all
transformation passes will preserve the ordering of
intrinsic-followed-by-operation. Is there a better way to do this?
-Dave
More information about the llvm-dev
mailing list