[PATCH] D50992: [InstCombine] try to fold insertelt + vector op into scalar op + insertelt

[Sanjay Patel via Phabricator via llvm-commits]

spatel created this revision.
spatel added reviewers: efriedma, lebedev.ri, reames.
Herald added a subscriber: mcrosier.

This is a transform suggested in PR37463:
https://bugs.llvm.org/show_bug.cgi?id=37463

This makes sense for IR because we should always have equal or better analysis for a scalar binop vs. a vector binop. It can also lead to follow-on transforms/simplifications as seen in some of the div/rem tests that change opcodes.

It's not as clearly a win for codegen (where keeping everything as vector ops might be better for perf), but I haven't seen any regressions yet, and it should be possible to reverse this if needed.

A couple of details worth pointing out:

1. This does not need to be limited with isSafeToSpeculativelyExecute() like the related shuffle transforms in this function. We're doing strictly less work by only operating on 1 lane of a vector, so there's no opportunity for executing on unknown bits. So div/rem are included in the diffs.
2. As noted in the last code comment, we can't just insert into an undef vector constant because that could be more undef than the original code was. But we'll probably end up inserting into an undef vector anyway in most cases because that's what the constants simplify to (as seen in the test results).


https://reviews.llvm.org/D50992

Files:
  lib/Transforms/InstCombine/InstructionCombining.cpp
  test/Transforms/InstCombine/inselt-binop.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D50992.161540.patch
Type: text/x-patch
Size: 32244 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180820/60c920e1/attachment.bin>