[PATCH] D58877: [InstCombine] fold add(add(A, ~B), 1) -> sub(A, B)

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 12 14:16:45 PDT 2019


spatel added a comment.

In D58877#1426695 <https://reviews.llvm.org/D58877#1426695>, @deadalnix wrote:

> @spatel I'm not sure, you tell me :) The history of this patch is that this pattern shows up in practice post legalization, so I submitted a patch for it for DAGCombiner. From there, @ lebedev.ri noticed that InstCombine wasn't doing it and suggested it to be added there as well.
>
> As far as I can tell, -reassociate also fails to trigger this transform: https://godbolt.org/z/gweK6j


You have to run reassociate before instcombine to get the expected ranking of operands:
https://godbolt.org/z/5XHhTh

So I agree that we needed the backend patch, but I don't see any evidence that this is needed within instcombine yet. The difference is that - in the backend - DAGCombiner is doing the job of both of the IR passes (reassociate is a canonicalization pass that works with instcombine). If we don't see this pattern after a normal IR optimization sequence, then I don't think we want to add it to instcombine (it would likely infinitesimally increase compile-time with no potential benefit). One way to see if there's any benefit to this patch would be to add a transform statistic, build the test-suite or some other substantial codebase, and see if this transform ever fires.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58877/new/

https://reviews.llvm.org/D58877





More information about the llvm-commits mailing list