[llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR

[John McCall via llvm-dev]

On 21 May 2020, at 16:01, Chris Tetreault wrote:
> Hi John,
>
>    I’d like to address some points in your message.
>
>> Practically speaking, this is going to break every out-of-tree 
>> frontend, backend, or optimization pass that supports SIMD types.
>
> My understanding is that the policy in LLVM development is that we do 
> not let considerations for downstream and out-of-tree codebases affect 
> the pace of development.

This is not categorically true, no.  When we make changes that require 
large-scale updates for downstream codebases, we do so because there’s 
a real expected benefit to it.  For the most part, we do make some 
effort to keep existing source interfaces stable.

> The C++ API is explicitly unstable. I maintain a downstream fork of 
> LLVM myself, so I know the pain that this is causing because I get to 
> fix all the issues in my internal codebase. However, the fix for 
> downstream codebases is very simple: Just find all the places where it 
> says VectorType, and change it to say FixedVectorType.
>
>> … by having the VectorType type semantically repurposed out from 
>> under them.
>
> The documented semantics of VectorType prior to my RFC were that it is 
> a generalization of all vector types. The VectorType contains an 
> ElementCount, which is a pair of (bool, unsigned). If the bool is 
> true, then the return value of getNumElements() is the minimum number 
> of vector elements. If the bool is false, then it is the actual number 
> of elements. My RFC has not changed these semantics. It will 
> eventually delete a function that has been pervasively misused 
> throughout the codebase, but the semantics remain the same. You are 
> proposing a semantic change to VectorType to have it specifically be a 
> fixed width vector.

Probably 99% of the code using VectorType semantically requires it to be 
a fixed-width vector.  The generalization of VectorType to scalable 
vector types was a representational shortcut that should never have been 
allowed; it should always have used a different type.  Honestly, I’m 
not convinced your abstract base type is even going to be very useful in 
practice vs. just having a `getVectorElementType()` accessor that checks 
for both and otherwise returns null.

>> … a particular largely-vendor-specific extension …
>
> All SIMD vectors are vendor specific extensions. Just because most of 
> the most popular architectures have them does not make this not true. 
> AArch64 and RISC-V have scalable vectors, so it is not just one 
> architecture. It is the responsibility of all developers to ensure 
> that they use the types correctly. It would be nice if the obvious 
> thing to do is the correct thing to do.

I’m not saying that we shouldn’t support scalable vector types.  
I’m saying that the burden of generalization should usually fall on 
the people who need to use the generalization, and otherwise we should 
aim to keep APIs stable when there’s no harm to it.

>> … it’s much better for code that does support both to explicitly 
>> opt in by checking for and handling the more general type …
>
> This is how it will work. I am in the process of fixing up call sites 
> that make fixed width assumptions so that they use FixedVectorType.

Are you actually auditing and testing them all to work for scalable 
vector types, or are you just fixing the obvious compile failures?  
Because scalable vector types impose some major restrictions that 
aren’t imposed on normal vectors, and the static type system isn’t 
going to catch most of them.

>    I think that it is important to ensure that things have clear 
> sensible names, and to clean up historical baggage when the 
> opportunity presents.

“Vector” has a traditional and dominant meaning as a fixed-width 
SIMD type, and the fact that you’ve introduced a generalization 
doesn’t change that.  Clang supports multiple kinds of pointer, but we 
still reserve `clang::PointerType` for C pointers instead of making it 
an abstract superclass, thus letting our sense of logic introduce a 
million bugs through accidental generalization throughout the compiler.

You have resigned yourself to doing a lot of work in pursuit of 
something that I really don’t think is actually an improvement.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200521/9344b3c5/attachment.html>