[llvm-dev] Use Galois field New Instructions (GFNI) to combine affine instructions
Adrien Guinet via llvm-dev
llvm-dev at lists.llvm.org
Tue May 19 00:58:51 PDT 2020
On 5/19/20 2:23 AM, Craig Topper wrote:
> I'm guessing AggressiveInstCombine only runs once in the pipeline and its
> probably before the vectorizers. Its existing transforms probably output
> things the vectorizer can understand and vectorize. In your case you're
> fully dependent on vectorized code.
Yes. I think it would generate more efficient code if I would do the combination within
the loop vectorization algorithm (that is, if I understood correctly, in VPlan). It would
for instance give more opportunity to "hide" the latency of GF2P8AFFINEQB, by e.g fine
tuning the loop unrolling factor. But I have to take more time to figure out how to make
this happen.
> We don't like to form target specific intrinsics in the middle end
> pipeline. We'd prefer to do something in the X86 specific IR pipeline or
> Machine IR pipeline run by llc. Or have a generic concept in IR that we can
> express like llvm.ctlz, llvm.cttz, llvm.popcnt or llvm.bitreverse. We have
> methods in TargetTransformInfo to query for targets supporting them or in
> the worst case we're able to generate reasonable code if the target doesn't
> support it natively.
I thought about putting that in the X86 pipeline, but it might remove some opportunities:
* supporting equivalent instructions from another vendor without rewriting everything
* fine tuning the loop vectorization process like said above
The approach with defining a generic intrinsic in the IR can be an interesting one, the
remaining question would be which API should we put there, so that it's generic enough (to
be a generic intrinsic) but doesn't prevent some optimization opportunities. That being
said, something like:
llvm.gf2p8.XX(<i8, XX> value, <i8, XX> matrix, i8 cst)
seems reasonnable to me.
I guess that's the eternal debate on where optimization X should happen and how... :)
> I'll try to point some more people here at Intel towards this thread.
Thanks a lot!
Adrien.
More information about the llvm-dev
mailing list