This is an archive of the discontinued LLVM Phabricator instance.

[SystemZ] Accept more constant FP BuildVectors.
AbandonedPublic

Authored by jonpa on Feb 12 2019, 12:03 PM.

Details

Reviewers
uweigand
Summary

I could not simply revert the recent removal of some FP BuildVecotr tests, but by using a new method ​isBuildVectorAllLegalFPImms() to check if all the operands of the BVN are legal FP immediates, more cases than just all-ones or all-zeros can be left as-is during legalization.

This does make most of the recently removed test functions pass again, except for f3 and f4 in vec-const-06.ll, which involved constants only producible with VGBM. We don't do this for FP constants as they are thought to not be useful in practice.

f3: removed: VGBM FP constants: <2 x double> <double 0xFF000000FFFF0000, double 0xFFFFFF00FFFF00>
f4: replaced VGBM FP constant to all-ones: <double 0xff000000ffff0000, double undef>

This patch changes one file on SPEC (/447.dealII/build/sparse_matrix_ez.float.s), with 8 x vgmg -> vgbm, which seems to be the inverse change from the recent VGBM commit.

Diff Detail

Event Timeline

jonpa created this revision.Feb 12 2019, 12:03 PM

Hmm. Actually, I'm now wondering why we need to reject anything in the first place. Can't we improve isFPImmLegal to accept *anything* that can be constructed via any of the vector instructions (VGBM, VGM, VREPI)?

Bascially, if we have a float X, it can be loaded as FP immediate if BUILD_VECTOR (X, undef, ...) can be loaded, and should thus be considered legal. And if we do that, then any float X that occurs as any component of a BUILD_VECTOR that can be loaded, can itself can also be loaded (that's obvious if BUILD_VECTOR can be loaded via replication, and also true if BUILD_VECTOR can be loaded via VGBM since you just need to shift the mask) and is therefore legal and wouldn't cause the BUILD_VECTOR to be forced to the constant pool.

So in end, we just need two routines:

  • can a FP immediate or BUILD_VECTOR be loaded?
  • actually load a FP immediate or BUILD_VECTOR

Both routines should work on BUILD_VECTORs and FP immediates (the FP immediate case could be handled by constructing BUILD_VECTOR (X, undef ...), but it's probably simpler to just hande the cases directly). The first of those routines would then be called both from lowerBUILD_VECTOR and isFPImmLegal, and the second routine would be called in ::Select for the BUILD_VECTOR and ConstantFP cases.

Does this make sense? It may not make much difference on benchmarks, but just as a general principle if we have an instruction that can do something, we should be using it, if it's possible without a lot of overhead ...