[llvm-dev] Vector Splitting for Stackmap Operands

[Philip Reames via llvm-dev]

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>