<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div class="moz-cite-prefix">On 11/30/20 11:28 AM, Florian Hahn wrote:<br>
</div>
<blockquote type="cite" cite="mid:3636426E-73A3-48C6-B6AB-DA0F3E596DC7@apple.com">
Hi<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 25, 2020, at 16:45, Simon Moll via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi,<br class="">
<br class="">
How can we make InstSimplify/InstCombine work with intrinsics?<br class="">
<br class="">
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:<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D92086" moz-do-not-send="true">
https://reviews.llvm.org/D92086</a><br class="">
<p class="">The patch includes tests where InstSimplify optimizes @llvm.vp.add and @llvm.experimental.contrained.fadd as a proof of concept.<br class="">
</p>
<p class="">The idea is to pretend that the intrinsics were the actual instruction (eg an
<tt class="remarkup-monospaced">fadd</tt>) 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.</p>
<p class="">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).</p>
</div>
</div>
</blockquote>
</div>
<div class="">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!</div>
<div class=""><br class="">
</div>
<div class="">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.
<br>
</div>
</blockquote>
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.<br>
<br>
To make InstCombine (ie emitting IR) work, you need to two things:<br>
1.) Make the matcher context collect all information from the pattern that is needed to replace it with new code.<br>
For VP, that's the match root's %mask and %evl. For constrained FP and complex you need no further info.<br>
<br>
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.<br>
Eg, for VP when told to emit an `fadd`, it emits a llvm.vp.fadd with the %mask and %evl from the matcher context.<br>
For constrained FP and complex, it will emit the corresponding intrinsics (with default FP round/except mode).<br>
<br>
- Simon<br>
<br>
Cheers,
<blockquote type="cite" cite="mid:3636426E-73A3-48C6-B6AB-DA0F3E596DC7@apple.com">
<div class="">Florian</div>
<div class=""><br class="">
</div>
<div class=""><br>
</div>
</blockquote>
<br>
</body>
</html>