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

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.