[PATCH] D29631: SystemZTargetTransformInfo cost functions and some common code changes

Jonas Paulsson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 11 22:27:53 PDT 2017


jonpa added inline comments.


================
Comment at: lib/Target/SystemZ/SystemZTargetTransformInfo.cpp:758
+    // Give a slight penalty for moving out of vector pipeline to FXU unit.
+    if (Index == 0 && Val->getScalarType()->isIntegerTy())
+      Cost += 1;
----------------
uweigand wrote:
> jonpa wrote:
> > uweigand wrote:
> > > Why just index == 0 ? Shouldn't the penalty apply to any element?
> > While the extraction of any element still has a modeled cost of 1 per element, my idea with this is to penalize further the delay of the act of moving out of the vector pipeline. This would then not be per element, but rather for the whole vector register (thus added only once, at index 0). My assumption is that this happens at the point of scalarization, when all vector elements are extracted.
> Why would this not be per element?   Moving from the vector to the integer pipeline always has the higher latency, for every element.  In the end any such extracton gets implemented using a VLVG* instruction, which simply is more expensive than other vector instructions ...  (Note that in the scheduler, the higher latency for VLVG* is already modeled correctly.)
I agree that this should be experimented further with, but the practical argument right now is that I added the smallest possible extra penalty to get rid of a particular regression while affecting code as little as possible. I consider this to be just a first step with obvious improvements in sight for the vectorizers decisions.

I thought the cost here was mainly that the vector register has to pass through the whole vector pipeline. I also imagine the VLGV* instructions would be pipelined, so that the cost of them is not a linear sum in the number of elements? Or is it really twice as expensive to scalarize a <4 x i32> rather than a <2 x i64>?



https://reviews.llvm.org/D29631





More information about the llvm-commits mailing list