Spill Weight In InlineSpiller

Project Infrastructure LLVM Dev List Archives
1

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.

Thanks,

Austin Kerbow

2

Hi Austin,

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

3

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

4

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?

Yes, it does.

If yes, how do we enable that?

It should be used by default for the existing allocators. To use in a new pass, you need to request the MachineBlockFrequencyInfo analysis.