pmatos wrote: cc: @nikic @jcranmer-intel @tlively @asb
I am looking for suggestions for a way forward on this. Issue #69894 triggers the SLPVectorizer that tries to create a vector of 2 externref and calculate its cost. Externref is a WebAssembly type currently represented as a pointer to a "magical" address space (address space 10). The other reference type is funcref that is a pointer to address space 20. As a pointertype, `VectorType::isValidElementType` returns true. The "obvious" solution is to say that if the target is webassembly and the type is a pointer type to address space 10 or 20, then it's not a valid element type. This is what I am doing (except actually checking the current target) which I am not sure how to obtain from `Type.cpp` at this point. However, this would introduce a target dependence which I think is not really something we want in `Type.cpp`. The other more radical alternative is to refactor the reference types approach in WebAssembly and use the new-ish TargetExtType. It feels like that's what we would have used had they existed when we initially worked on this. Alas, they didn't exist and we used the magic of address spaces to solve the issue. This refactoring would lead to possibly quite a bit of work, including touching clang to correct the lowering of these types. In addition it might also open a Pandora's box. I wonder if there's a middle ground here somewhere that doesn't involve adding target dependence to Type.cpp but at the same time doesn't require a full refactoring of these types. ............... Why is the test failing? In SLPVectorizer.cpp we are generating the type `<16 x ptr addrspace(10)>` and calling `llvm::TargetTransformInfo::getNumberOfParts` on it. This will down the line call `getTypeLegalizationCost` for this type. The MVT for an externref is MVT::externref. The MVT for a vector of these is `iPTR`. At some point `getTypeForEVT` in `ValueTypes.cpp:198` it asserts `Assertion isExtended() && "Type is not extended!"' failed.`. I attempted this with a pointer to int instead of externref because it should work the same. And it does without failing (obviously). This is because the type created is `<4 x ptr>`. The MVT for a `i32` is `MVT::i32` and the MVT for the vector is `MVT::v4i32`. This is extended and nothing asserts. https://github.com/llvm/llvm-project/pull/71069 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits