[PATCH] D32352: Go to eleven

[Andrew V. Tischenko via Phabricator via llvm-commits]

avt77 added a comment.

>> It's already limited:
>> 
>>   // An imul is usually smaller than the alternative sequence.
>>   if (DAG.getMachineFunction().getFunction()->optForMinSize())
> 
> Ah, sorry I missed that. The fact that it is "MinSize" highlights that we're in a gray area for the DAG. That is, it's hard to know what the best sequence will be without looking at the instruction timing. Given that, we need to know if converting these muls is generally good. Do you have real or synthetic benchmark info for these cases? Is there a perf difference, for example, between Jaguar and Haswell (since those CPUs are specified in the tests)? Is the codegen ever different for those CPUs? If not, why are we adding different RUNs for them in this patch?

The idea of different runs was to be able to see the perf numbers in the test for different CPUs: if we see right numbers then it's easy to see the profit if it is. Unfortunately the current numbers are wrong from my point of view and should be fixed.

> The hope is that in the longer term this can all be converted to MC patterns and driven by the scheduler models, but for that we need decent scheduler modelling of LEA (PR32326). In the meantime we might be better off only using multiple LEA calls when !Subtarget->slowLEA() ? In which case we need to add tests for silvermont

The question is: should we check "!Subtarget->slowLEA()" for ALL such optimizations or for NEW ones only? On the other hand I added speciall switch "mul-constant-optimization". At the moment it controls the new optimizations only and it's TRUE by default. I could extend its influence on all MULT-LEA optimizations and set it FALSE by deafault. As result we'll be able to see perf numbers for all possible variants and later (on MC level) we'll be able to select really profit patterns.


https://reviews.llvm.org/D32352