<div dir="ltr">Hi Alex,<div><br></div><div>I'm not sure I understand how this map works. A single Value * may have a StructType which is initially represented by a MERGE_VALUES node. But that node will be removed in DAGCombine by connecting each operand of the MERGE_VALUES to the users of each of the results. At that point there is no single SDValue that represents the Value *. How does the map model this? </div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 31, 2021 at 10:38 AM Alex Susu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Hello, llvm-dev.<br>
I am trying to commit in the following weeks the back end I wrote for our research <br>
lab's Connex SIMD processor, a promising vector processor which we hope to make it visible <br>
(please see if you have the time these links related to the Connex processor: <br>
<a href="https://dl.acm.org/doi/10.1145/3406536" rel="noreferrer" target="_blank">https://dl.acm.org/doi/10.1145/3406536</a>, <br>
<a href="http://users.dcae.pub.ro/~gstefan/2ndLevel/functional_electronics.html" rel="noreferrer" target="_blank">http://users.dcae.pub.ro/~gstefan/2ndLevel/functional_electronics.html</a> ).<br>
<br>
But, since our back end has the exotic feature of handling symbolic immediate <br>
assembler operands to achieve vector-length portability by using JIT assembling I had to <br>
make a small change to the SelectionDAG class which I now would like to commit on Github.<br>
<br>
So I come to ask you what do you think about adding this useful small feature in the <br>
SelectionDAG class (a DenseMap<const Value*, SDValue> *crtNodeMapPtr datastructure and a <br>
bit of book-keeping for it).<br>
<br>
From <a href="https://reviews.llvm.org/D60052#change-7t38wfUuDjbR" rel="noreferrer" target="_blank">https://reviews.llvm.org/D60052#change-7t38wfUuDjbR</a> (my previous attempt to <br>
commit the Connex backend):<br>
> As written at <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-May/132133.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-May/132133.html</a>:<br>
> There is one thing a bit more special with this back end, namely our back<br>
> end handles symbolic immediate operands (C/C++ expressions written as strings in <br>
INLINEASM MachineInstrs). This means the back end can output vector assembly code like:<br>
> VLOAD Reg0, N * 10 + 5 // where N is a variable in the original C program,<br>
which means that to assign to register Reg0 the value N*10 + 5. This instruction is <br>
later JIT assembled (at runtime) in order to have a constant immediate operand equal to<br>
N*10 + 5<br>
> Therefore, in order to support recovering from a SelectionDAG node to LLVM IR <br>
(and then all the way back to the original source C/C++ code), something possible with the <br>
current LLVM distribution, which is implemented in our Connex LLVM compiler project, we <br>
require adding a simple data structure in the LLVM source file:<br>
> include/llvm/CodeGen/SelectionDAG.h (and helper methods in the related<br>
> SelectionDAG.cpp file)<br>
> that maps an SDValue to the LLVM IR Value object it was used to translate <br>
from called:<br>
> DenseMap<const Value*, SDValue> *crtNodeMapPtr .<br>
<br>
Roman Lebedev asked me about this new feature that I propose, at <br>
<a href="https://lists.llvm.org/pipermail/llvm-dev/2019-May/132136.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2019-May/132136.html</a><br>
> I'm not sure how that is supposed to work. What if IR does not originate from C?<br>
> How do you verify that the "C string" is in the form that will be understood<br>
> by whatever will handle it later on? Is there a clang part of the patch?<br>
My answer to his question is: the IR originates from C and there is no clang patch, <br>
since there is no need to alter clang. To recover a C/C++ expression from SelectionDAG <br>
node to LLVM IR (and then all the way back to the original source C/C++ code) we only need <br>
to add this crtNodeMapPtr data structure. The recovery is performed by walking recursively <br>
on the LLVM IR code starting from the immediate operand of the assembler instruction until <br>
the end: the moment we visit an LLVM IR add instruction we simply put in the resulting <br>
C/C++ string we create a "+" operator.<br>
<br>
This recovery from SelectionDAG node to LLVM IR and then to C/C++ is working very well <br>
in my LLVM build. It is well tested on a few tenths of small benchmarks.<br>
<br>
Please let me know if you have any questions related to this proposed small change to <br>
the SelectionDAG class. You can find some more explanation on how we recover to C/C++ in <br>
my PhD thesis: see Section 4.1.8 ("Symbolic Scalar Immediate Operands") at <br>
<a href="https://sites.google.com/site/alexsusu/myfilecabinet/PhDThesis_AlexSusu.pdf" rel="noreferrer" target="_blank">https://sites.google.com/site/alexsusu/myfilecabinet/PhDThesis_AlexSusu.pdf</a> .<br>
<br>
<br>
Thank you,<br>
Alex<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>