[llvm-dev] Vector Splitting for Stackmap Operands

[Yihan Pang via llvm-dev]

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>