[PATCH] D18841: [InstCombine] Canonicalize icmp instructions based on dominating conditions.
David Majnemer via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 28 15:16:23 PDT 2016
majnemer added a comment.
In http://reviews.llvm.org/D18841#416085, @bmakam wrote:
> In http://reviews.llvm.org/D18841#415959, @majnemer wrote:
>
> > Generally speaking, InstCombine canonicalization helps out down stream analysis by simplifying the IR or exposes further opportunities for canonicalization. i'm not entirely sure that this transform fits that bill.
>
>
> FWIW, the examples listed in the testcases demonstrate that it helps out by simplifying the IR. In my tests on spec2006 benchmarks it has reduced more than 3000 static instructions in xalancbmk and 100s of static instructions in gcc and several other benchmarks. This is similar to the transformations done in FoldAndOfICmps except that here we consider dominating condition as the LHS. I have constrained this only to the first predecessor to find the dominating icmp and could still remove several static instructions which should improve the code quality and compile time.
Does this result in instructions removed at the LLVM IR or does it result in fewer instructions emitted in the backend?
If it results in fewer IR instructions, can you determine why this is the case? If it results in the same number of IR instructions, then performing this transform might make more sense in CodeGenPrepare.
> > I wonder if a more appropriate place for this to live is in CodeGenPrepare seeing as how sensitive this transform is to the peculiarities of the target ISA, perhaps with a TargetLowering check which verifies that it would make sense to perform on such a target.
>
>
> I am not totally against moving this to the backend and infact I started off by implementing it at the very end of the pipeline in http://reviews.llvm.org/D18572, but realized that it would catch more such cases and might help other downstream optimizations when we do this transform in instcombine. What do you think?
I would have done this optimization a little earlier at around the CodeGenPrepare level.
http://reviews.llvm.org/D18841
More information about the llvm-commits
mailing list