[PATCH] D27695: Add Instruction number to LSR cost model (PR23384)

Evgeny Stupachenko via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 20 17:40:04 PST 2016


evstupac added a comment.

Hi Quentin,

Thanks for taking a look.

> Like Wei, I'd like #3 to be a separate patch.
>  Indeed, #1 and #2 should be NFC as long as the targets do not change the cost model.

Ok. I'll split the patch.
However #3 without #2 has almost no effect. So the following order seems the best #1, #3, #2.

Thanks,
Evgeny



================
Comment at: lib/Target/X86/X86TargetTransformInfo.cpp:1874
+                    C2.NumIVMuls, C2.NumBaseAdds,
+                    C2.ScaleCost, C2.ImmCost, C2.SetupCost);
+}
----------------
qcolombet wrote:
> Do you have data to support that heuristic?
> Like Wei said, I suspect this may lead to pretty bad side effect where we will increase the register pressure by a lot to save a few instruction.
> So before we switch the default, I want supportive evidence that this is general goodness.
> 
> For the record, we discuss with Wei this cost model issue and I still have on my todolist a better register pressure estimation for the loop. E.g., we can ignore NumRegs as long as it is below the regpressure.
>Do you have data to support that heuristic?
Yes on spec2000:

177.mesa on -O2 +3%
256.bzip2 on -Ofast -flto +1.5%

There are gains on EEMBC tests. I don't see any significant (>2% regressions). And I'm waiting for data from Wei.
However I agree that for better testing we can introduce an option like -lsr-count-insns.

> E.g., we can ignore NumRegs as long as it is below the regpressure.
That is roughly estimated in my patch. When TTI.getNumberOfRegisters(false) - 1 is exceeded we start to increment instruction counter (1 insn per 1 new register). In most cases that is enough to take a solution with low register pressure.




Repository:
  rL LLVM

https://reviews.llvm.org/D27695





More information about the llvm-commits mailing list