<div dir="ltr">Everything you just described sounds like expected behavior. To make your system more reliable, you will probably need some kind of precisely specified LLVM intrinsic and MachineInstr pair with precise semantics that the rest of the optimizers can reason about. I am reminded of the convergent attribute redesign and the challenges in the AMDGPU backend.<div><br></div><div>However, nobody has pointed out yet MachineInstr::setPostInstrSymbol, so let me mention it:</div><div><a href="https://llvm.org/doxygen/classllvm_1_1MachineInstr.html#ac8ce95857a66b3706a84d1fd5072f0dd">https://llvm.org/doxygen/classllvm_1_1MachineInstr.html#ac8ce95857a66b3706a84d1fd5072f0dd</a><br></div><div>This API is a bit dangerous, because unless you are confident that optimizers will not delete or duplicate your MachineInstr, you can end up with zero or two or more label definitions. However, it works reasonably well for tracking function call return addresses in debug info, or in late stage passes after branch folding.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 3, 2020 at 6:36 AM Diogo Sampaio 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">
<div>
<p>Thanks for the replies Tim and Jason,</p>
<p>So I went for the idea of using a pseudo-instruction that is
expanded to a label.<br>
In my particular case, it is just the label delimiting a hardware
loop end. And I have another one<br>
for the loop start. I'm simply lowering the IR generated
intrinsics into pseudo-instructions<br>
(actually replacing the conditional branch that makes the loop
latch).</p>
<p>From doing that I had issues with branchFolding doing some
undesired changes, as it does not see the loop structure no more.<br>
I managed to get it to work by using hasAddressTaken /
labelMustBeEmitted to the loop latch block, and make analyzeBranch<br>
return that it can't compute the branches when the basic block
holds one of the pseudo instructions.<br>
However it seems that is over-constraint branchFolding, and the
code is not that optimal in the end, but it works.<br>
</p>
<p>But I'm still having issues from instructions moving across the
loop boundaries.<br>
I found out that setting the pseudo-instructions as a
"isSchedulingBoundary" helps with the schedulers, but still,<br>
when reg-allocator is synthesizing phi-nodes into instructions,
some are converted inside/outside the loop in wrong manner.<br>
So I have to search for where to insert the instructions and some
times move some instruction around. But that's not that<br>
trivial in some cases.<br>
<br>
If I define the pseudo instructions as branch instructions I guess
that should be enough for forcing the loop structure to be
maintained, right?<br>
Is there any special thing I need to do other then managing to
place them in end of a MBB and make analyzeBranch understand them?<br>
</p>
<p>Alternatively, looking from changes in the HardwareLoops pass and
some current upstream diffs, it seems I'm not the only one having
such sort of issues.<br>
Could that be solved in a more generic manner? Perhaps teaching
the compiler about Hardware[Machine]Loops (being a sub-classes of
[Machine]Loops).<br>
At IR level the loop intrinsics would delimit the loop start/end.
At MIR level, it would query the TargetTransformInfo for which are
the loop boundaries instructions<br>
(an start and a latch instructions).<br>
That could guide the backend optimizations, (scheduler, branch
folding ... including the reg-alloc to correctly place phi nodes).
Does that seems a reasonable idea?<br>
</p>
<p>One last question, more a aesthetic thing which I hadn't time to
look into... When the pseudo instruction is expanded<br>
to a label it still gets indented. Is there any special
instruction type or a flag to tell it is a label so it should not
be indented?<br>
Or is there a special manner to print labels?<br>
(I'm simply setting the instruction with isCodegenOnly=1 and using
the asm string as "$label:", which is one of the operands.<br>
</p>
<p>Cheers.</p>
<p>Diogo.<br>
</p>
<div>On 02/12/2020 22:51, Tim Northover
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Wed, 2 Dec 2020 at 17:32, Diogo Sampaio via llvm-dev
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><llvm-dev@lists.llvm.org></a> wrote:
</pre>
<blockquote type="cite">
<pre>Is there a straight-forward way to obtain an arbitrary MachineInstruction address and maintain it updated along the backend optimizations, even if it is in the middle of a MachineBasicBlock?
I have an instruction that takes a relative address. E.g
</pre>
</blockquote>
<pre>I added a similar feature to AArch64 recently to handle jump-tables. I
think tracking both BB-start and offset is probably a non-starter, so
to take vocabulary from your example I implemented something like:
myInstruction Ltmp0
[...]
BBN:
... x instructions ...
Ltmp0:
target_instruction
In this situation target_instruction is a Pseudo-instructrion that
gets expanded at the AsmPrinter stage into a label followed by the
real instruction. Both myInstruction and target_instruction would
share some kind of immediate operand saying which instance they are,
and the symbol generated would be coordinated by XYZFunctionInfo
(first user asks for a temporary symbol and records it there).
If target_instruction could actually be lots and lots of different
alternatives that you don't want to create pseudos for then you may be
able to arrange a bundle with a label-pseudo and the real instruction.
I just mention this so you don't abandon the idea entirely, I can give
more details if needed.
Cheers.
Tim.
</pre>
</blockquote>
<br>
<div>On 02/12/2020 18:50, Jason Eckhardt
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I have a somewhat similar scenario in a downstream back-end. You
might try #2 and then call one of:<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
/// Set this block to reflect that it potentially is the
target of an indirect branch.
<div> void setHasAddressTaken() { AddressTaken = true; }</div>
<div><br>
</div>
<div> /// Test whether this block must have its label emitted.</div>
<div> bool hasLabelMustBeEmitted() const { return
LabelMustBeEmitted; }</div>
</div>
</blockquote>
</div>
_______________________________________________<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>