[PATCH] D71636: [AArch64][SVE][WIP] Add support for vscale constants (?)

Sander de Smalen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 7 05:50:46 PST 2020


sdesmalen added a comment.

In D71636#1807522 <https://reviews.llvm.org/D71636#1807522>, @simoll wrote:

>   define i32 @vscale() {
>     ret i32 ptrtoint (<vscale x 1 x i8>* getelementptr (<vscale x 1 x
>   i8>, <vscale x 1 x i8>* null, i64 1) to i32)
>   }
>   
>
> Whether this returns `vscale` or something else depends on the ptrtoint mapping of the default address space.. and `<vscale x 1 x i8>* null` might not be `i32 0` for some targets. You might get away with subtracting the integer value of `null` ;-) (.. i guess @arsenm is more familiar with the topic of address spaces and what may be assumed about them given his recent DevMtg talk).


My understanding was that for the default address space, `nullptr` always has the bit value `0`. I don't really understand this topic enough to know the intricacies around the ptrtoint mapping of the default address space, but if this is used for `sizeof`, I don't see why it couldn't be used for `vscale` (taking into account the check for larger alignment).

The main argument for wanting vscale as a constant was to avoid copy propagation (because it is inherently a constant value) to benefit ISel and to use VScale in shuffle masks to e.g. represent zips or concats. We can drop the latter requirement if we come up with alternative ways to address shuffles for scalable vectors. With the right safe-guards with respect to datalayout, we can still use Eli's suggestion to implement the copy propagation and still benefit from the constant expression with some help from PatternMatch. I've updated my original vscale patch to reflect that: D68203 <https://reviews.llvm.org/D68203>.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71636/new/

https://reviews.llvm.org/D71636





More information about the llvm-commits mailing list