[llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR
David Greene via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 12 09:13:55 PDT 2020
Sander De Smalen via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Even when it requires some code duplication, I prefer being more
> explicit in distinguishing these types (option 3), over adding
> conversion functions between Type and Composite/SequentialType
> (options 1 and 2), especially when the conversion may not always be
> safe. I'm concerned that requiring conversion functions makes the code
> less readable, like this example from D65486:
>
> if (auto *STy = dyn_cast_or_null<llvm::SequentialType>(
> llvm::CompositeType::get(OrigTy, false)))
>
> Here the use of CompositeType::get(Type*) in the context of
> dyn_cast_or_null<llvm::SequentialType> seems a bit obscure to me.
>
> If we are to choose for option 3, I'd suggest removing the interface
> to 'Type::getSequentialNumElements()' entirely, and replacing it by
> explicit `Type::getFixedVectorNumElements()` and
> `Type::getArrayNumElements()`, thus removing any methods that mimic
> the old design.
+1.
-David
More information about the llvm-dev
mailing list