This is an archive of the discontinued LLVM Phabricator instance.

[mlir][spirv] Add math to OpenCL conversion
ClosedPublic

Authored by Hardcode84 on Nov 12 2021, 9:25 AM.

Diff Detail

Event Timeline

Hardcode84 created this revision.Nov 12 2021, 9:25 AM
Hardcode84 requested review of this revision.Nov 12 2021, 9:25 AM
antiagainst requested changes to this revision.Nov 15 2021, 12:41 PM
antiagainst added inline comments.
mlir/include/mlir/Conversion/MathToSPIRV/MathToSPIRVPass.h
20 ↗(On Diff #386872)

There is no need to create separate passes; should use the target environment.

mlir/lib/Conversion/MathToSPIRV/MathToSPIRV.cpp
80–95

This isn't the proper way to handle conversions; we should rely on the target environment. Let me explain a bit more on this here:

The conversion patterns to SPIR-V should not concern about the legality of the generated op in the target environment. That's entirely the job of the dialect conversion framework. In SPIR-V, we clearly define the required version/extension/capability for all the ops and then wires up them to the dialect conversion legality check. When the dialect conversion happens, _all_ patterns will be tried (both for Vulkan and OpenCL) but _only_ those patterns generating ops allowed in the target environment can succeed because of the legality check there. By this, we have a clear separation of concerns and all the patterns can be written in a simple way, without requiring each pattern to consider its interaction with other patterns and the target environment. If you'd like to control which patterns apply, you should set the proper target environment.

There is actually one example for CmpFOp showing how to write patterns in such a way and selectively apply patterns according to the target environment. (Well sort of I guess. ;-P)

In the above we are trying to apply patterns selectively according to the target environment. The difference there though is it is for core vs kernel. So we use pattern benefits to make sure kernel patterns prevail if kernel is allowed in the target environment. Those two patterns are written entirely without knowledge of that and the populate* entry point does not have the switch for it.

In this patch we are trying to do it for vulkan for opencl; they are of equal footing from SPIR-V conversion's perspective; so we don't need to adjust benefits. We just need to make sure the version/extension/capability requirements are properly declared in all ops and you have the proper target environment when doing conversion. Then everything should just work.

I guess right now we miss proper version/extension/capability declarations for those extended instruction set ops. If you put the following to the main SPV_OCLOp definition:

list<Availability> availability = [
  MinVersion<SPV_V_1_0>,
  MaxVersion<SPV_V_1_5>,
  Extension<[]>,
  Capability<[Extension]>
];

It should fix. (Also need to put Shader capability requirements for all GLSL extended ops.)

Does this make sense? Happy to explain more if anything is unclear. :)

This revision now requires changes to proceed.Nov 15 2021, 12:41 PM

use capability

kpet added a subscriber: kpet.Nov 23 2021, 8:53 AM
antiagainst accepted this revision.Nov 23 2021, 1:51 PM

Awesome, thanks!

This revision is now accepted and ready to land.Nov 23 2021, 1:51 PM
This revision was automatically updated to reflect the committed changes.