<div dir="ltr"><div dir="ltr"><div dir="ltr">Hello Dominik,<div><br></div><div>As you mentioned, I suggest converting it to COPY now when lowering to GlobalISel.</div><div><br></div><div>The later pipeline of freeze was intentionally left as lowered into COPY right now, because</div><div>(1) There was a suggestion that we can simply make IMPLICIT_DEF yield the same value whenever it was read (currently it is allowed for IMPLICIT_DEF to return different values whenever read).</div><div>This means that FREEZE in MIR isn't needed, and lowering FREEZE to COPY becomes sound.</div><div>(2) Existing optimizations in the upper level aren't friendly with the new instruction, and teaching them seemed a high priority to me.</div><div><br></div><div>Regarding the future work for lowering the instruction into MIR, there is no clear winner for which strategy to take yet:<br></div><div>If IMPLICIT_DEF can yield different values whenever read, this allows generation of better assembly, but requires introduction of FREEZE into MIR.</div><div>If reading the IMPLICIT_DEF register yields the same value, its semantics becomes clearer/easier & FREEZE is not needed in MIR, but codegen may not be optimal.</div><div><br></div><div style="color:rgb(0,0,0)">Changes in GlobalISel should have been in the patch, but it was omitted. I'm sorry for that happening.</div><div style="color:rgb(0,0,0)"><br></div><div>Thanks,</div><div>Juneyoung Lee</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 6:47 PM Dominik Montada 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
After a recent upstream merge into our downstream sources we are <br>
suddenly encountering the freeze instruction in LLVM IR for div/rem <br>
pairs. This seems to be related to [1].<br>
<br>
Our downstream target is GlobalISel only and unfortunately GlobalISel <br>
doesn't support this instruction yet, so most of our internal test-suite <br>
is now breaking due to GlobalISel not being able to translate this <br>
instruction to MIR. We would like to add support for that, but it seems <br>
that it is not yet clear how this freeze instruction is supposed to look <br>
like in MIR.<br>
<br>
In [2], which introduced the FREEZE node to SelectionDAG, there was a <br>
lengthier discussion which concluded that for now proper handling was <br>
only added to SelDAG and the MIR related patches would be left for a <br>
follow up. We would like to accelerate this follow up, because we <br>
obviously want to get our downstream backend working again.<br>
<br>
One part of this discussion concerned how freeze should behave on MIR <br>
level. Especially if there needs to be a MIR FREEZE instruction and <br>
whether the semantics of IMPLICIT_DEF need to be changed.<br>
<br>
In SelectionDAG, FREEZE is currently handled as a simple COPY. This <br>
seems to me like SelectionDAG ignores the semantics of FREEZE, since <br>
COPY has other semantics? Also, would this be acceptable for the <br>
GlobalISel IRTranslator (even if only as a first step)?<br>
<br>
Best regards,<br>
<br>
Dominik<br>
<br>
[1] <a href="https://reviews.llvm.org/D76483" rel="noreferrer" target="_blank">https://reviews.llvm.org/D76483</a><br>
[2] <a href="https://reviews.llvm.org/D29014" rel="noreferrer" target="_blank">https://reviews.llvm.org/D29014</a><br>
<br>
P.S.: is there really no way to disable a single pass from command line? <br>
We would like to disable the DivRemPairs pass as a first workaround.<br>
<br>
-- <br>
----------------------------------------------------------------------<br>
Dominik Montada                   Email: <a href="mailto:dominik.montada@hightec-rt.com" target="_blank">dominik.montada@hightec-rt.com</a><br>
HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19<br>
Europaallee 19                    Fax:   +49-681-92613-26<br>
D-66113 Saarbrücken               WWW: <a href="http://www.hightec-rt.com" rel="noreferrer" target="_blank">http://www.hightec-rt.com</a><br>
<br>
Managing Director: Vera Strothmann<br>
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222<br>
<br>
This e-mail may contain confidential and/or privileged information. If<br>
you are not the intended recipient please notify the sender immediately<br>
and destroy this e-mail. Any unauthorised copying, disclosure or<br>
distribution of the material in this e-mail is strictly forbidden.<br>
---<br>
<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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div>