This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Add support for lowering vector operations to scalar.
Needs ReviewPublic

Authored by Sonicadvance1 on Mar 11 2018, 6:12 PM.

Details

Summary

Previously when attempting to legalize operations on architectures that
don't have true vector operation support the backend would need to do
the lowering by itself. This allows the legalizer to handle this situation by itself.

Here's the bugzilla for this: https://bugs.llvm.org/show_bug.cgi?id=36618

Diff Detail

Repository
rL LLVM

Event Timeline

Sonicadvance1 created this revision.Mar 11 2018, 6:12 PM
  1. Please *always* upload all diffs with the full context (-U999999)
  2. Tests?

Updated the diff with as much context as possible

As far as I'm aware it is impossible to write unit tests for this unless a backend uses it?
I've attempted adding this to AArch64's GlobalISel implementation and hit other deficiencies in the backend that are unrelated but this code uncovered.

As far as I'm aware it is impossible to write unit tests for this unless a backend uses it?
I've attempted adding this to AArch64's GlobalISel implementation and hit other deficiencies in the backend that are unrelated but this code uncovered.

Wouldn't you be able to write unit tests for this by extending unittests/CodeGen/GlobalISel/LegalizerInfoTest.cpp?

kristof.beyls added inline comments.Mar 12 2018, 8:20 AM
lib/CodeGen/GlobalISel/LegalizerHelper.cpp
1077–1080

I guess the FIXME should be removed, and the condition in the if statement could become an assert?
Vectors are always an exact multiple of a number of individual elements?

1088

I guess the code will read more natural if you don't try to stick very closely to the variable names used in the other lowering helper methods, but e.g. instead of "NumParts" use "NumElements" here?
Similarly maybe use "ElementTy" instead of "NarrowTy" and "ElementSize" instead of "NarrowSize"?

Addressed the comments about readability and added a unit test for the decomposing.
Had to add a specialization that uncovered an issue where vectors with only one element aren't allowed to be generated.

Sonicadvance1 marked 2 inline comments as done.Mar 17 2018, 4:36 PM
kristof.beyls added inline comments.Mar 26 2018, 7:41 AM
include/llvm/CodeGen/GlobalISel/LegalizerHelper.h
91

Just a nit pick: I think "scalarizeVector" sounds more natural and in a similar style as the other methods here than "scalarElementsVector".
What do you think?

include/llvm/CodeGen/GlobalISel/LegalizerInfo.h
75

I think that similarly, "Scalarize" here might be less confusing that "LowerScalar".
"WidenScalar" and "NarrowScalar" already exist and do something on Scalar data types - for "LowerScalar" one could then also guess it does something on scalar data types which it doesn't. I think "Scalarize" is less ambiguous.

371

To be consistent with earlier comments: maybe best to change the method name to "scalarizeFor"?

lib/CodeGen/GlobalISel/LegalizerHelper.cpp
1075

This is over 80 characters long. Please run clang-format on the whole patch.

1081

I would have assumed that G_FMA has Operands 0, 1, 2, and 3; but I see only Operands 0, 1 and 2 being handled here.
I guess either G_FMA must be removed as a case from this switch statement and an assert added here that the number of operands is exactly 3; or the code should be made more generic to be able to handle generic opcodes with more input operands?

unittests/CodeGen/GlobalISel/LegalizerInfoTest.cpp
206–210

This suggests that you need to call the setAction API for every combination of (number of elements, element size) vector.
That doesn't scale.
Can you rewrite this in a simple way to represent that all vectors - irrespective of number of elements or element size - need to be scalarized for a given opcode?
e.g. something similar to the setLegalizeVectorElementToDifferentSizeStrategy API in tests higher up in this function.
Maybe a new function call in the API at that level needs to be introduced to be able to represent this?