[llvm-dev] [InstCombine] Simplification sometimes only transforms but doesn't simplify instruction, causing side effect in other pass

[Matthias Braun via llvm-dev]

> On Aug 2, 2017, at 4:29 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Wed, Aug 2, 2017 at 4:07 PM Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> On Aug 2, 2017, at 4:00 PM, Wei Mi <wmi at google.com <mailto:wmi at google.com>> wrote:
>> 
>> On Wed, Aug 2, 2017 at 3:36 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote:
>>> So to write this in a more condensed form, you have:
>>> 
>>> %v0 = ...
>>> %v1 = and %v0, 255
>>> %v2 = and %v1, 31
>>> use %v1
>>> use %v2
>>> 
>>> and transform this to
>>> %v0 = ...
>>> %v1 = and %v0, 255
>>> %v2 = and %v0, 31
>>> ...
>>> 
>>> This is a classical problem with instruction combining. When you replace a non-root node of a pattern (in this case %v2 would be the root pattern we match, but we actually replace %v1 with %v0 as part of the replacement) and that non-root node has multiple users then it becomes very hard to predict whether the transformations pays off in the end.
>>> 
>>> In my experience it is best to restrict those sort of transformation to situations where you can prove there aren't multiple users on the intermediate/non-root node that we replace. (Or if you want to get fancier that all users
>>> will match the same pattern).
>>> 
>>> - Matthias
>> 
>> Thanks Matthias, yes, the transformation in instcombine is of non-root
>> node pattern. What I am worried about to add the restriction that %v1
>> has to have only one use is that such change may regress some
>> benchmarks. For the same case, after we add the limitation, we will
>> save a move in BB1, but may add another move in BB2, because %v2 and
>> %v1 are both alive after %v2 = and %v1, 31.  Which choice is better
>> depends on the hotness of BB1 and BB2, so the result of such
>> transformation in instcombine is like flipping a coin.  Currently we
>> don't have a pass to use BFI to do such transformation in a meaningful
>> way. Maybe we need such a pass, and with that pass, we can disable the
>> transformations in instcombine without regressing certain benchmarks.
> 
> Yes this strategy will regress some situations and also goes against the LLVM spirit of perform as much normalization as possible in the middle end.
> 
> On the other hand eagerly transform all such opportunities has more potential to regress things than to improve things in my experience, especially since we currently have no way of reverting this transformation.
> 
> There are many cases where we have no way of reverting this transformation, but it seems like this is not one of those cases.
> 
> It seems like we could, potentially very late (not sure how late, maybe in remat itself? maybe earlier...), recognize that we can reduce the live value set by rewriting %v2 in terms of %v1 (in your reduced example). Even something as simple as demanded-bits should be able to tell that %v0 and %v1 are interchangeable.

This is also a mostly neutral example. I don't know 

> 
> But maybe there is something about this live-set-reduction transform that is hard? I've not thought about it much.
It certainly seems feasible and would be a cool project. There is some space here, where we get less register pressure but also less ILP when serializing here.

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170802/90169c4c/attachment.html>