llvm dev - Aug 2020 - [RFC] Replace `unsigned VF` with `ElementCount VF` [NFCI]

Francesco,

   I think this is a good approach. ElementCount is the value that the vector
types themselves use to describe their size, we should just use that everywhere
we talk about the sizes of vectors. This seems like a good start, and will allow
us to add scalable vector functionality one bit at a time.

Thanks,
   Christopher Tetreault

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Francesco
Petrogalli via llvm-dev
Sent: Tuesday, August 11, 2020 3:58 PM
To: Hassoubi, Hicham via llvm-dev <llvm-dev at lists.llvm.org>
Cc: nd <nd at arm.com>
Subject: [EXT] [llvm-dev] [RFC] Replace `unsigned VF` with `ElementCount VF`
[NFCI]

Hi all,

I am working on replacing `unsigned VF` with `ElementCount VF` in the
vectorizer.

I have submitted an RFC patch to fabricator just to show how it looks like:
https://reviews.llvm.org/D85794

Just to be clear. I am not trying to get this patch in as it is, I am just
asking for some feedback on the approach.

The changes in the vectorizer are numerous, but mostly mechanical.

I have explained in the description of the patch the changes, which fall in two
categories:

1. changes outsize the vectorizer, which are needed to be able to query things
like "how many lanes" are in this "vectorization factor", or
to print things to debug streams or remarks.
2. changes in the vectorizer that are needed to guarantee a _non functional
change_, for example asserting that the ElementCount instance being used to
compute a vector reverse cannot be scalable. The code essentially looks the same
as before this patch, other than for the fact that I have added such assertions.

I am aware the changes in LoopVectorizer.cpp might be a lot. I am open to
consider different incremental approaches.
One data point here is that my initial approach was to add the `bool Scalable`
property to the VectorizationFactor class.
However, using ElementCount instead of the pair {unsigned, bool} for dealing
with the number of lanes inside the VectorizationFactor seemed a natural choice
that was worth investigating.

Please let me know what you think!

Kind regards,

Francesco


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev