[llvm-dev] Cleaning up ‘br i1 false’ cases in CodeGenPrepare

[Friedman, Eli via llvm-dev]

On 6/29/2018 3:25 PM, George Burgess IV wrote:
> > we lower llvm.objectsize later than we should
>
> 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.

After the "simplification" part of the optimization pipeline (after 
we've finished inlining and the associated function simplification 
passes have run), we're unlikely to find new information that would help 
simplify an llvm.objectsize or llvm.is.constant call.  So roughly around 
EP_VectorizerStart is probably appropriate.  But someone should measure 
before we move it.

-Eli

>
> (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, ...)
>
> On Fri, Jun 29, 2018 at 12:21 PM Friedman, Eli via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On 6/28/2018 9:44 PM, Bharathi Seshadri via llvm-dev wrote:
>     > Hi,
>     >
>     > I have come across a couple of cases where the code generated after
>     > CodeGenPrepare pass has "br i1 false .." with both true and false
>     > conditions preserved and this propagates further and remains the
>     same
>     > in the final assembly code/executable.
>     >
>     > In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which
>     > handles the br i1 false condition) is called only once and if after
>     > the transformation of code by ConstantFoldTerminator() and
>     > DeleteDeadBlock() we end up with code like "br i1 false", there
>     is no
>     > further opportunity to clean them up. So calling this code under
>     > (!DisableBranchOpts) in a loop until no more transformations are
>     made
>     > fixes this issue. Is this reasonable ?
>
>     I would expect the precise case you're running into is rare: the
>     second
>     iteration of the loop does nothing useful unless the IR
>     specifically has
>     an i1 phi node in a block whose predecessors were erased.  And the
>     default optimization pipeline runs SimplifyCFG at the very end,
>     which is
>     close to CodeGenPrepare, so the CFG simplification will usually be a
>     no-op anyway.
>
>     We really shouldn't be doing this sort of folding in
>     CodeGenPrepare in
>     the first place.  It looks like it was added to work around the fact
>     that we we lower llvm.objectsize later than we should.
>
>     -Eli
>
>     -- 
>     Employee of Qualcomm Innovation Center, Inc.
>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>     a Linux Foundation Collaborative Project
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180629/845f27f6/attachment.html>