[PATCH] D42267: [ThinLTO] Allow 0 to be a valid value for pruning interval for C LTO API.

Katya Romanova via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 19 13:16:23 PST 2018


kromanova added inline comments.


================
Comment at: tools/llvm-lto/llvm-lto.cpp:161
+    ThinLTOCachePruningInterval("thinlto-cache-pruning-interval", 
+    cl::init(1200), cl::desc("Set ThinLTO cache pruning interval."));
 
----------------
bd1976llvm wrote:
> Under what circumstances does this change have an effect? 
> 
> I remember that the same default is set in the CachePruningPolicy constructor.
Before my change in llvm-lto.cpp we effectively overwrote the default value of PruningInterval, initializing it with 0.

```
ThinLTOProcessing(const TargetOptions &Options) {
    ...
    ThinGenerator.setCacheDir(ThinLTOCacheDir);
    ThinGenerator.setCachePruningInterval(ThinLTOCachePruningInterval);  //set PruningInterval to 0
    ThinGenerator.setFreestanding(EnableFreestanding);
    ...
}
```  
All other knobs (e.g. Expiration or MaxSizePercentageOfAvailableSpace) determining the pruning policy are not being set in llvm-lto.cpp, 
so they keep the default values assigned by CachePruningPolicy constructor.
With my change, we keep the default value (1200) for PruningInterval.

Why this is needed? I guess for consistency. When I wrote my tests, I compared the default pruning policy behavior with the behavior when PruningInterval == 0. 
I was puzzled to notice that the behavior was the same. Only then I noticed that we are intentionally setting the value 0 to PruningInterval in llvm-lto.cpp.
I decided to fix it. However, if this behavior is undesirable, I don't mind to change my test to explicitly pass option for setting PruningInterval value for both of the tests, rather than using a default value.



Repository:
  rL LLVM

https://reviews.llvm.org/D42267





More information about the llvm-commits mailing list