This patch legalizes the Machine Value Type introduced in https://reviews.llvm.org/D94096 for loads and stores. It's notable to point out that the function that chooses an EVT for a given llvm type now needs to be specialized (dynamically binded) per target, as for AArch64 and only when the LS64 extension is present I am mapping [8 x i64] to MVT::i64x8, which would otherwise be MVT::Other since it's an aggregate type.
This looks like it turns all [8 x i64] IR types into i64x8, which is pretty risky.
At the very least it means we probably need to add new tests for any natural IR operation you can do to that type (load, store, extract, insert, alloca, GEP, phi, select, function calls & returns and anything else you can think of to throw at it).
To be clear, the risky part is making getValueType() do this universally, for every place where you can write [8 x i64] in LLVM IR. Adding a target hook specifically for inline asm operands should be fine.
Changes since last revision:
- getAsmOperandValueType() is a target hook called only when the selection DAG is processing Inline Asm nodes
- GlobalISel was crashing before and now it just falls back to Selection DAG.
It's a little unfortunate we're sticking this in target-independent code, but not sure there's a better place.
Not sure why you're marking BITCAST Legal; there isn't any legal type to bitcast from.
I guess LOAD/STORE come out of type legalization?
Not, I am afraid.
I think that's a leftover from previous efforts, so as the UNDEF just below. I'll remove them.
These are the custom lowering operations for the load/store i512 instruction that clang inserts pre/post inline assembly for accessing the asm operands (see lines 4569 and 4595).
This should be TargetLowering::getAsmOperandValueType. I'll fix it.
Changes in this revision:
- Removed BITCAST and UNDEF from the legal operations on MVT::i64x8
- Rectified the derived target hook getAsmOperandValueType() to call the parent as a fallback instead of getValueType()