[LoadStoreVectorizer] Consider if operation is faster than before

[rampitec]

Summary

Compare a relative speed of misaligned accesses before and
after vectorization, not just check the new instruction is
not going to be slower.

Since no target now returns anything but 0 or 1 for Fast
argument of the allowsMisalignedMemoryAccesses this is still NFCI.

The subsequent patch will tune actual vaues of Fast on AMDGPU.

[foad]

llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp

1089

It is not at all clear to me whether it makes sense to compare FastBefore with Fast directly, or whether one of them needs to be multiplied by ChainSize. Especially since the definition of Fast is target-specific.

[rampitec]

llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp

1089

I thought about this, but 'fast' is not an actual memory transfer speed like Gb/s, it is a speed rank. Defining real memory speed will be hard to do, especially given alignment considerations. I do not think this is additive like a cost. It can be compared, but hardly added or multiplied. More so when an ultimate 'slow' is still zero.

[rampitec]

Rebased.

[arsenm]

llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp

1084–1085

Maybe rename to RelativeCost or something?

[rampitec]

Renamed 'Fast' used in the file to 'RelativeSpeed'.

[foad]

llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp

1089

I still don't understand how generic code can meaningfully compare, for example, one load with speed rank 42 vs two loads with speed rank 99. Are you supposed to ignore the number of loads completely, and just compare the speed rank numbers?

[rampitec]

llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp

1089

Yes, the rank behaves more like a throughput. It is not precisely a throughput because nobody can guarantee it, but a similar concept.

[rampitec]

ping

[rampitec]

ping