[PATCH] Select elimination pass

Eric Christopher echristo at gmail.com
Thu Sep 4 12:48:28 PDT 2014


On Thu, Sep 4, 2014 at 12:41 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at gmail.com>
> > To: "Gerolf Hoflehner" <ghoflehner at apple.com>
> > Cc: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> > Sent: Thursday, September 4, 2014 2:14:53 PM
> > Subject: Re: [PATCH] Select elimination pass
> >
> >
> >
> >
> >
> >
> > On Thu, Sep 4, 2014 at 11:20 AM, Gerolf Hoflehner <
> > ghoflehner at apple.com > wrote:
> >
> >
> > This is a good question. InstCombine is a local pattern matcher at
> > the instruction level. I did not want adding a global flavor by
> > introducing the dominator tree in that pass.
> >
> >
> > This is an interesting point. Despite not having a dominator tree,
> > there are parts of InstCombine that already approximate dominance
> > information by scanning instructions or checking parent basic
> > blocks.
> >
> >
> > I think we should seriously consider adding DominatorTrees to
> > InstCombine rather than adding more passes. I'm not aware of
> > anything that would make this particularly hard or expensive...
>
> FWIW, I've looked at this in the context of dealing with @llvm.assume. I
> plan to, at least, make InstCombine grab DT when it is otherwise available.
> As it turns out, in the standard pipeline, this happens at least once.
>
>
It makes sense and it'll likely give us a combine that's a little less
hacky than "quick, follow these few instructions around and see what they
do".

-eric


>  -Hal
>
> >
> >
> > Also I would have to mess around with the combiner logic when
> > inserting an instruction like an “or” which is not the immediate
> > replacement instruction of the select.
> >
> >
> > This shouldn't be too bad. There are other places where we combine
> > somewhat specific uses or instruction patterns.
> >
> >
> > I also looked at the SimplifyCFG and if-conversion code, but none
> > seem a natural fit for this optimization.
> >
> >
> > I agree here.
> >
> >
> > I’m not super happy about a new pass but it looked like the kleinstes
> > Uebel among the choices.
> > Yea, I'm very unconvinced about adding a new pass here. Consider that
> > this is quite likely to expose more instruction combining
> > opportunities, or to be enabled by some other instruction combining.
> > It really needs to be in the iterative worklist IMO.
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140904/bf7b35ca/attachment.html>


More information about the llvm-commits mailing list