[PATCH] D92086: Generalized PatternMatch & InstSimplify

[Simon Moll via Phabricator via llvm-commits]

simoll marked an inline comment as done.
simoll added a comment.

In D92086#3536474 <https://reviews.llvm.org/D92086#3536474>, @rengolin wrote:

> First, I think this is a good idea and can eventually mitigate the general problem of intrinsics vs. instructions in other LLVM passes.

Thanks for chiming in!

> But I worry we'll end up with too many traits to emulate actual instructions' semantics and we'll go back to the discussions of how much an intrinsic is like an instruction.
>
> As an example, for one type of transformation (say constant folding) an intrinsic-add "acts like an add" (precision), but another transformation (ex loop induction) it doesn't (wrapping semantics).
>
> So, while we can come up with a list of traits that make this one particular match work, we may be faced with a combinatorial number of traits to generalise it to other transformations.
>
> I don't have any particular case in mind, just the general feeling that we'll get stuck half-way through and have to keep a set of traits that can't be easily used by other passes.
>
> But this is not a negative view, just perhaps a request for clarification: how much else did you look at to make sure this can extend to more intrinsics and passes?

I did not look into the generality of the approach beyond InstSimplify/Combine. The traits, as defined right now, are really specific to that use case. InstSimplify/Combine is really where the demand is for the intrinsics as far as i am aware.

Other intrinsic types for InstCombine could be saturating int arithmetic, complex arithmetic and, maybe, matrix intrinsics.

You could try to generalize the trait approach for all kinds of analyses and transformations. I am not sure it's worthwhile though.
If you did, what could happen in the worst case, if specific traits are not general enough and we insisted on generalizing the approach to all passes? If you wrote one trait per set of intrinsics and pass that would get you somewhere in O(#passes x #intrinsic_types) in terms of number of trait classes - that's not really a combinatorial explosion. Even in this scenario, which we would not blindly walk in to, you are getting something in return: those passes start working on the intrinsics.

> Second, there are a lot of clang-format changes on unrelated code lines and it makes it hard to see what's just reformatted and what's really changed.

D126783 <https://reviews.llvm.org/D126783> should help with that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92086