[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