This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Fix warnings in getCopyFromPartsVector
AbandonedPublic

Authored by david-arm on Jun 1 2020, 5:46 AM.

Details

Summary

Replace some of the calls to getVectorNumElements() with
getVectorElementCount(). These warnings were being hit by
this test:

llvm/test/CodeGen/AArch64/sve-gep.ll

As part of this patch I have introduced another comparison
operator in ElementCount, namely to check if one count
is > than another. However, when doing mathematical
operations we do not always know the answer at compile
time and therefore we have two functions:

bool isGT(const ElementCount &RHS, bool &Known);
bool knownGT(const ElementCount &RHS);

The first function returns true if the answer is known at
compile time to be >, otherwise it returns false. The Known
boolean is set true if the answer is known at compile time.

The second function also does the comparison, but asserts
that the answer is known at compile time.

Diff Detail

Unit TestsFailed

Event Timeline

david-arm created this revision.Jun 1 2020, 5:46 AM
rovka added a subscriber: rovka.Jun 2 2020, 5:01 AM
rovka added inline comments.
llvm/include/llvm/Support/TypeSize.h
56

Is it ever safe to ignore the value of Known? If not, I'd suggest making this method private so people are forced to use knownGT. Alternatively, you could define a 'compare' function and have it return an enum value saying Unknown, GT, LE etc.

64

To be honest I find this whole sequence a bit difficult to follow. Shouldn't Known only be true if LHS and RHS are either both scalable or both fixed? If so, then you can just say Known = (Scalable == RHS.Scalable). Similar to how it's handled for TypeSize. This looks like another argument in favor of the alternative design with an enum, which just separates these concerns and makes you decide up front whether or not it's possible to make the comparison.

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
443

If we know that the vector element types are the same, can't we just compare the type sizes here and piggy-back on the comparison operators we already have instead of adding new ones?

david-arm marked 3 inline comments as done.Jun 2 2020, 5:44 AM

I'll give this patch some more thought for now and see if I can just simply remove the assert in getCopy...

llvm/include/llvm/Support/TypeSize.h
56

I think it's more the other way around really. In many cases we will probably be trying to apply an optimisation based on whether the result is true or false. If the answer cannot be determined (Known=false), then we shouldn't be applying that transformation or going down that particular code path. I'll think more about this though and perhaps I can refactor the existing code in getCopyFromParts such that we don't even need to ask this question.

64

So the Min variable represents the absolute minimum number of elements. Therefore, when LHS is a fixed width vector the element count is guaranteed to always be <=the element count of RHS, regardless of whether it's scalable or not. Hence the odd looking code! I could always return "Known = false" when Scalable != RHS.Scalable, but I just thought we can cover more cases than that.

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
443

So we can't really piggyback on the TypeSize class here as they are quite different classes, although I could certainly duplicate the operators. The operators in TypeSize simply assert that both LHS and RHS are either fixed or scalable types. I guess this will often be the case, but is not guaranteed. To be honest, TypeSize and ElementCount will need to be refactored at some point to make use of some common base class.