[PATCH] D32737: [Constants][SVE] Represent the runtime length of a scalable vector

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 21 04:38:44 PDT 2017


rengolin added inline comments.


================
Comment at: lib/IR/Constants.cpp:812
+  // Free the constant and any dangling references to it.
+  getContext().pImpl->VSVConstants.erase(getType());
+}
----------------
sanjoy wrote:
> rengolin wrote:
> > aemerson wrote:
> > > rengolin wrote:
> > > > So, in theory, you can have vscale constans of different integer types, and this would only clear the ones that are the same as this one? 
> > > > 
> > > > This sounds confusing.
> > > Yes, in the same way you can have i32 undef, i64 undef etc.
> > Right, makes sense.
> Is there a minimum width, or is (say) an `i1 vscale` allowed?  If there isn't a minimum, I presume the semantics is that the runtime value of `vscale` will be truncated to the type width?
The vscale does not define the vector length. That is defined by the CPU (via a status register) at runtime.

The *exact* same code can run in one process with length = 10 and another with length = 1. In theory, the same binary could run one instruction with 10 and the very next with 1 (that'd be crazy, but valid).

However, one instruction being executed by the unit will operate on identical lengths. Ie. you can't have two vectors of different sizes on the same "add". AFAIK this is not just illegal, it's theoretically impossible, from where that information comes from.

What's illegal (and probably traps) is if you set the status register to a value that is larger than the actual physical length, but that will never be generated by the compiler (which has no business setting the length at all), so it's not something the compiler should worry about.


https://reviews.llvm.org/D32737





More information about the llvm-commits mailing list