[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.



More information about the llvm-dev mailing list