With support now in the new LTO API for caching (r279576), add
optional ThinLTO caching in the gold-plugin.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 | I just noticed: this is largely suboptimal, the Buffer will be a mmap'd file in memory, and you're duplicating it here. |
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 | I didn't notice earlier because the libLTO interface returns a pointer to the memory to the linker, so the MemoryBuffer is untouched till the linker needs it (it does not need to be paged in memory, which can contributes to explains why you have much more memory pressure) |
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 |
Dumb question - where is the duplication happening? getBuffer will give back a StringRef to the memory pointed to by the MemoryBuffer. And we then stream it to an output file (which we would have done earlier without caching). |
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 | The StringRef points to the memory mapped from the cache. So this is data on disk that you load in memory while you access it here. |
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 | Ah ok, yes the file is duplicated unfortunately (temporarily), gold cleans up the temp object files written here. I didn't noticed a memory increase from this change. Not sure if there is a way for gold-plugin to pass back the native object in memory, but I don't see a hook for that unfortunately. |
llvm/trunk/tools/gold/gold-plugin.cpp | ||
---|---|---|
812 | Even if the peak memory does not increase, the memory traffic (and cache trashing) is probably important (let along that these data need to be flushed to disk...) |
I just noticed: this is largely suboptimal, the Buffer will be a mmap'd file in memory, and you're duplicating it here.