[llvm-dev] [RFC] Generalized Pattern Matching & InstSimplify

Simon Moll via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 30 02:54:58 PST 2020


On 11/30/20 11:28 AM, Florian Hahn wrote:
Hi

On Nov 25, 2020, at 16:45, Simon Moll via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi,

How can we make InstSimplify/InstCombine work with intrinsics?

This RFC proposes generalized pattern matching to lift LLVM's existing InstSimplify to work on intrinsics as well as on regular instructions. For details, technical discussion, please refer to:

    https://reviews.llvm.org/D92086

The patch includes tests where InstSimplify optimizes @llvm.vp.add and @llvm.experimental.contrained.fadd as a proof of concept.

The idea is to pretend that the intrinsics were the actual instruction (eg an fadd) and run the existing InstSimplify logic. We augment pattern matching with a context object - if during pattern matching the context object is no longer sure that the intrinsics are a safe match (eg because there may be fp exceptions that we need to preserve), it aborts the match. In effect, only legal simplifications are performed.

We expect the approach to work as well for the [proposed] complex arithmetic intrinsics (by masking regular `fmul` and making `llvm.complex.fmul` pass as `fmul` instead).

Thanks for sharing the RFC. It looks like this should be flexible enough to handle a wide range of intrinsics that can be mapped to IR instructions in InstSimplify!

Do you think this approach would also work for InstCombine? Unfortunately there are lots of places that pass references to actual IR instructions to helper functions, rather than (OpCode, Operands...) as instSimplify.
Yes, this also works for InstCombine. Passing references actually makes it more robust because you can swap the actual IR instruction class for a helper that transparently mimics an IR instruction. Those are already in the patch as`ExtInstruction<Trait>`, `ExtBinaryOperator<Trait>`, etc.

To make InstCombine (ie emitting IR) work, you need to two things:
1.) Make the matcher context collect all information from the pattern that is needed to replace it with new code.
For VP, that's the match root's %mask and %evl. For constrained FP and complex you need no further info.

2.) Specialize `TraitBuilder<Trait>` for your trait. That class is constructed with the matcher context. It emits intrinsics when it is told to emit the "real" IR instruction.
Eg, for VP when told to emit an `fadd`, it emits a llvm.vp.fadd with the %mask and %evl from the matcher context.
For constrained FP and complex, it will emit the corresponding intrinsics (with default FP round/except mode).

- Simon

Cheers,
Florian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201130/7c62e871/attachment.html>


More information about the llvm-dev mailing list