paulwalker-arm wrote:
Sorry for the delay and thanks for the investigation @rj-jesus. This is sooooo
not intentional behaviour. VLS based auto vectorisation was implemented before
the VLS ACLE extensions and by that time it's likely fixed length calls to
`llvm.vscale()` were constant folded away and so never made it to code
generation, hence why we've survived this long without being bitten.
I think the problem sits in `getMemVTFromNode()` which is implemented too
literally when considering fixed length vectors. The function should be return
the memory footprint of the operation and for that only the element type of the
MemVT matters because that is what governs when extension/truncation must be
considered.
I've quickly tested the following, which corrects the behaviour for your test
case but I've not investigated what other nodes need to be handled so as not to
hit the unreachable.
```
static EVT getMemVTFromNode(LLVMContext &Ctx, SDNode *Root) {
- if (isa<MemSDNode>(Root))
- return cast<MemSDNode>(Root)->getMemoryVT();
+ if (isa<MemSDNode>(Root)) {
+ EVT MemVT = cast<MemSDNode>(Root)->getMemoryVT();
+
+ EVT DataVT;
+ if (auto *Load = dyn_cast<LoadSDNode>(Root))
+ DataVT = Load->getValueType(0);
+ else if (auto *Load = dyn_cast<MaskedLoadSDNode>(Root))
+ DataVT = Load->getValueType(0);
+ else if (auto *Store = dyn_cast<StoreSDNode>(Root))
+ DataVT = Store->getValue().getValueType();
+ else if (auto *Store = dyn_cast<MaskedStoreSDNode>(Root))
+ DataVT = Store->getValue().getValueType();
+ else
+ llvm_unreachable("Unexpected MemSDNode!");
+
+ return DataVT.changeVectorElementType(MemVT.getVectorElementType());
+ }
```
Do you mind running with such an approach for your PR? If not, I'm happy to
finish it off and push a PR for yours to build upon.
https://github.com/llvm/llvm-project/pull/130625
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
