Yihan Pang via llvm-dev
2018-Feb-02 21:34 UTC
[llvm-dev] Vector Splitting for Stackmap Operands
HI All, I am current working with SIMD instruction along with stackmap features. Recently I encountered a problem involving legalizing stackmap. In my stackmap, I record all the live values existing at the callsite. One of the operands in my stackmap is an illegal vector type for arm64 architecture ( *v4f64*) and requires vector splitting in order to legalize the node ( *v2f64*). However, I noticed that in the *DAGTypeLegalizer::SplitVectorOperand* function, the switch case does not handle stackmap cases. So initially every time I run my code with *-mllvm -debug-only=legalize_types* I will get an error " Do not know how to split this operator's operand" My first attempt to fix this is to add an if statment before the switch case to see if the Node is referring to a stackmap, and if so I will get the SDNode of the particular stackmap operand using *N->getOperand(OperandNumber).getNode(); * and use that instead of the original SDNode in the switch case statement. For example, if I need to split the 3rd operand of my stackmap which is an vector operand I will create a *SDNode* that equals to* N->getOperand(3).getNode()*; This attempt gives a failed assertion of " *Invalid node ID for RAUW deletion.*" My next attempt is to add additional instructions to replace the original illegal vector operand with the new resulting legal operand. This can be achieved using *ReplaceValueWidth* function (if the stackmap flag is set) to replace the original *SDValue* of the vector operand with the new Resulting Value (in the function it is denoted as *Res*) that resulted from *SplittingVecOp_*xxx function. However, this way I ran into other failed assertion at other locations. Right now I am not sure what is an effective way of handling stackmap vector operand in the legalizing phase and I appreciate any suggestions from the community Best, Yihan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180202/9f051b72/attachment.html>
Philip Reames via llvm-dev
2018-Feb-23 05:01 UTC
[llvm-dev] Vector Splitting for Stackmap Operands
On 02/02/2018 01:34 PM, Yihan Pang via llvm-dev wrote:> HI All, > > I am current working with SIMD instruction along with stackmap features. > > Recently I encountered a problem involving legalizing stackmap. In my > stackmap, I record all the live values existing at the callsite. One > of the operands in my stackmap is an illegal vector type for arm64 > architecture (/v4f64/) and requires vector splitting in order to > legalize the node (/v2f64/). However, I noticed that in the > /DAGTypeLegalizer::SplitVectorOperand/ function, the switch case does > not handle stackmap cases. So initially every time I run my code with > > /-mllvm -debug-only=legalize_types/ > > I will get an error " Do not know how to split this operator's operand"To start with, I don't think this is an area which has gotten lots of thought. We're by far the largest user of the stackmap infrastructure (via deopt operand bundles and patchpoint), and in our environment, all of our arguments are legal for our target. Given that, I think you're going to be stumbling into a lot of unexplored topics. If you can, I would seriously consider whether you can avoid needing to solve this during legalization. Can you instead split your stack map operands into legal (or at least trivial to legalize) sizes in your frontend? If you can't, can you clarify what your expectations are? In general, the stackmap tries to describe the locations of elements such that they can be easily found at runtime. What would you expect the stackmap to contain for your illegal vector type? i.e. what result are you looking for? Fair warning, I will likely not have bandwidth to respond to this going forward. I strongly suggest you take the time to draft any follow on questions carefully for minimal effort on the part of the reader. It's not that I'll intentional ignore you, but my todo list is always longer than my day. You really don't want to end up on the todo list if you can at all avoid it.> > My first attempt to fix this is to add an if statment before the > switch case to see if the Node is referring to a stackmap, and if so I > will get the SDNode of the particular stackmap operand using > > /N->getOperand(OperandNumber).getNode(); / > / > / > and use that instead of the original SDNode in the switch case statement. > > For example, if I need to split the 3rd operand of my stackmap which > is an vector operand > I will create a /SDNode/ that equals to/N->getOperand(3).getNode()/; > > This attempt gives a failed assertion of " *Invalid node ID for RAUW > deletion.*" > > My next attempt is to add additional instructions to replace the > original illegal vector operand with the new resulting legal operand. > This can be achieved using /ReplaceValueWidth/ function (if the > stackmap flag is set) to replace the original /SDValue/ of the vector > operand with the new Resulting Value (in the function it is denoted as > /Res/) that resulted from /SplittingVecOp_/xxx function. > > However, this way I ran into other failed assertion at other locations. > > Right now I am not sure what is an effective way of handling stackmap > vector operand in the legalizing phase and I appreciate any > suggestions from the community > > Best, > Yihan > > > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180222/fc7feb41/attachment-0001.html>
Maybe Matching Threads
- llvm-dev Digest, Vol 164, Issue 6
- [LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
- [LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal