[llvm-dev] [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!

Kristof Beyls via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 1 07:46:50 PDT 2017


On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at apple.com<mailto:qcolombet at apple.com>> wrote:

Latest comparisons on my side, after picking up r304244, i.e. the correct Localizer pass.
* CTMark compile time, comparing "-O0 -g" vs '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0': about 6% increase with globalisel. This was about 3.5% before the Localizer pass landed.

That one is surprising too. I wouldn’t have expected this pass to show up in the compile time profile. At least not to this extend.
What is the biggest offender?

Hmmm. So I took the 3.5% compile time overhead from my last measurement before the localizer landed, from around 24th of May.
When using -ftime-report, I see the Localizer pass typically taking very roughly about 1% of compile time.
Maybe another part of GlobalISel became a bit slower since I did that 3.5% measurement?
Or maybe the Localizer pass changes the structure of the program so that another later pass gets a different compile time profile?
Basically, I'd have to do more experiments to figure that one out.

As far as where time is spent in the gisel-passes itself, on average, I saw the following on the latest CTMark experiment I ran:
Avg compile time spent in IRTranslator: 4.61%
Avg compile time spent in InstructionSelect: 7.51%
Avg compile time spent in Legalizer: 1.06%
Avg compile time spent in Localizer: 0.76%
Avg compile time spent in RegBankSelect: 2.12%


* My usual performance benchmarking run: 8.5% slow-down. This was about 9.5% before the Localizer pass landed, so a slight improvement.
* Code size: 3.14% larger. This was about 2.8% before the Localizer pass landed, so a slight regression.

That one is surprising. Do you have an idea of what is happening?
Alternatively if you can point me to the biggest offender, I can have a look.

So the biggest offenders on the mem_bytes metric in LNT are:
        O0 -g   O0 -g gisel-with-localizer      O0 -g gisel-without-localizer
SingleSource/Benchmarks/Misc/perlin     14272   14640   18344   25.95%
SingleSource/Benchmarks/Dhrystone/dry   16560   17144   20160   18.21%
SingleSource/Benchmarks/Stanford/QueensProfile  13912   14192   15136   6.79%
MultiSource/Benchmarks/Trimaran/netbench-url/netbench-url       71400   72272   75504   4.53%

I haven't had time to investigate what exact changes make the code size go up that much with the localizer pass in those cases...


The only thing I can think of is that we duplicate constants that are expensive to materialize. If that’s the case, we were discussing with Ahmed an alternative to the localizer pass that would operate during InstructionSelect so may be worth pursuing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170601/2e115051/attachment.html>


More information about the llvm-dev mailing list