<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 21 May 2020, at 16:01, Chris Tetreault wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hi John,<br>
<br>
I’d like to address some points in your message.<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types.</p>
</blockquote><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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.<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">… by having the VectorType type semantically repurposed out from under them.</p>
</blockquote><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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 <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">getVectorElementType()</code> accessor that checks for both and otherwise returns null.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">… a particular largely-vendor-specific extension …</p>
</blockquote><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">… it’s much better for code that does support both to explicitly opt in by checking for and handling the more general type …</p>
</blockquote><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto"> I think that it is important to ensure that things have clear sensible names, and to clean up historical baggage when the opportunity presents.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">“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 <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">clang::PointerType</code> 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.</p>
<p dir="auto">You have resigned yourself to doing a lot of work in pursuit of something that I really don’t think is actually an improvement.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>