[llvm-dev] Vector Splitting for Stackmap Operands
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 22 21:01:14 PST 2018
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
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
> 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
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev