[llvm-dev] Spill Weight In InlineSpiller

[Shobaki, Ghassan via llvm-dev]

Hi Quentin,


Thanks for the reply! However, we are not using any profiling-based compilation in our current work. We are assuming that, if PGO is disabled, the register allocator (and any other pass that needs basic block frequency info) will be basing its decisions on some kind of *static" basic block frequency info that are based on some compile-time heuristics and at least capture loop nesting levels. With such static info, we don't expect see blocks with zero frequency; we expect a block outside all loops to have a frequency of 1 or some small non-zero number. Does LLVM compute such static info? If yes, how do we enable that?


Thanks


Ghassan Shobaki

Assistant Professor of Computer Science

California State University, Sacramento

________________________________
From: qcolombet at apple.com <qcolombet at apple.com> on behalf of Quentin Colombet <qcolombet at apple.com>
Sent: Wednesday, September 20, 2017 9:44:35 AM
To: Kerbow, Austin Michael
Cc: via llvm-dev
Subject: Re: [llvm-dev] Spill Weight In InlineSpiller

Hi Austin,

> On Sep 19, 2017, at 11:29 PM, Kerbow, Austin Michael via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> I'm trying to compute and print a weighted spill cost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me.

I don’t know how PGO is implemented in that respect so take it with a grain of salt, but if you’re using PGO, I am guessing that if something is not executed in your training run, you may end up with a 0 frequency.

That being said, I thought we had mechanism to prevent that for happening. Therefore, that sounds like a bug (or you’re looking at an unreachable block?)

Cheers,
-Quentin

>
> Thanks,
>
> Austin Kerbow
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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