<div dir="ltr"><div>> <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">we lower llvm.objectsize later than we should</span></div><div><br></div><div>Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity.</div><div><br></div><div>(To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just saying that if the ideal piece of code to do that isn't CGP, ...)</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 29, 2018 at 12:21 PM Friedman, Eli via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6/28/2018 9:44 PM, Bharathi Seshadri via llvm-dev wrote:<br>
> Hi,<br>
><br>
> I have come across a couple of cases where the code generated after<br>
> CodeGenPrepare pass has "br i1 false .." with both true and false<br>
> conditions preserved and this propagates further and remains the same<br>
> in the final assembly code/executable.<br>
><br>
> In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which<br>
> handles the br i1 false condition) is called only once and if after<br>
> the transformation of code by ConstantFoldTerminator() and<br>
> DeleteDeadBlock() we end up with code like "br i1 false", there is no<br>
> further opportunity to clean them up. So calling this code under<br>
> (!DisableBranchOpts) in a loop until no more transformations are made<br>
> fixes this issue. Is this reasonable ?<br>
<br>
I would expect the precise case you're running into is rare: the second <br>
iteration of the loop does nothing useful unless the IR specifically has <br>
an i1 phi node in a block whose predecessors were erased.  And the <br>
default optimization pipeline runs SimplifyCFG at the very end, which is <br>
close to CodeGenPrepare, so the CFG simplification will usually be a <br>
no-op anyway.<br>
<br>
We really shouldn't be doing this sort of folding in CodeGenPrepare in <br>
the first place.  It looks like it was added to work around the fact <br>
that we we lower llvm.objectsize later than we should.<br>
<br>
-Eli<br>
<br>
-- <br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>