Derive TTI instruction costs from scheduling models

[RKSimon]

Bugzilla Link	36550
Version	trunk
OS	Windows NT
Depends On	#31672 #37378 #36255 #36279
CC	@alexey-bataev,@adibiagio,@atrick,@topperc,@fhahn,@hfinkel,@rotateright

Extended Description

As discussed on D43769, we have a very divergent concept of costs between the different cost models that we use for each target (TTI, scheduling etc.).

It would be very useful to investigate whether we can begin replacing all these costs tables with values obtained directly from the target scheduling models, and begin standardizing their usage so that we can use them in more areas than just vectorization.

This will probably require a target to have models covering most/all of the CPU types to avoid us, which is why Florian suggested that AArch64 be used for initial experimentation.

[RKSimon]

assigned to @RKSimon

[atrick]

I didn't realize people were adding tables of vector latencies in TTI. It should just be a mapping to a sequence of machine opcode with the latencies derived from the machine model.

[RKSimon]

Looking at this now, and I have an initial prototype that I'm playing with.

The description in TargetTransformInfo.h suggests the cost should always be in ratio to an equivalent instruction for the scalar type. So a fdiv f32 will always have a cost of 1 and the fdiv vXf32 are compared against that.

e.g. Jaguar:
vdivss (f32) Throughput = 19cy
vdivps (v4f32) Throughput = 19cy, cost = 1
vdivpsy (v8f32) Throughput = 38cy, cost = 2

But would it not be better to to use a more generic throughput cost?

e.g. Jaguar:
vdivss (f32) cost = Throughput = 19cy
vdivps (v4f32) cost = Throughput = 19cy
vdivpsy (v8f32) cost = Throughput = 38cy

That way we can compare costs of other transforms, such as idiv vs a shift-mul-add sequence?

[alexey-bataev]

I agree that it would be better, the only concern I have is the overflow of the final cost. We should be very careful about that.

[RKSimon]

I've uploaded an initial RFC patch at https://reviews.llvm.org/D46276

[RKSimon]

mentioned in issue #36255

[RKSimon]

mentioned in issue #36279

[RKSimon]

mentioned in issue #37378