As promised, I’m working on follow-up toward AMX dialect cleanup using the same approach as for the x86vector.
In the meantime, the intrinsic generation infrastructure got some minor improvements after adding a few more intrinsic ops. Primarily, type conversion is now easier to handle compared to the first version.
Refactor proposal
Before getting to the dialect itself, I propose moving the intrinsic op interface to LLVMIR to allow easier code reuse. After the simplification, the low-level x86vector ops directly abstract concrete LLVM intrinsics which effectively creates strong direct dependency on LLVM.
AMX dialect ops can use the same design flow by either creating its own intrinsic interface or adding an extra dependency on x86vector to reuse its interface. However, the intrinsic modelling is already closely related to LLVMIR and currently its llvm.call_intrinsic op. Placing the intrinsic interface in the LLVMIR dialect would create more logical dependency stack and allow for easy code reuse - each low-level dialect such as x86vector, amx etc. could derive from that interface.
The implementation PR:
Note that x86vector still has its own light interface wrapper to allow for easy matching of all x86vector intrinsic ops without the risk of processing ops from other dialects (once more dialects use the base common interface). Perhaps, there’s a better approach to that.
Alternatives
Dialect-specific interfaces
Other dialects, like AMX, could have their own copies of the intrinsic op interface - essentially copy-paste of the x86vector interface.
That would work fine but feels like unnecessary code duplication. I aim for the intrinsic interface to be generic enough to serve as a common bridge between low-level ops and call to intrinsics. Having one base interface would help to polish it further if needed and promote reuse.
Different interface location
Right now, it seemed the easiest to throw the interface into LLVMInterfaces.
However, there could be a better place for that. I think it conceptually belongs to LLVMIR dialect but it could be better to give it own separate place like LLVMExtInterfaces.
No strong opinions here.