[PATCH] D19644: [ThinLTO] Option to control path of distributed backend files

[Teresa Johnson via llvm-commits]

tejohnson added a comment.

In http://reviews.llvm.org/D19644#421867, @tejohnson wrote:

> In http://reviews.llvm.org/D19644#421629, @joker.eph wrote:
>
> > Can this be exposed to `llvm-lto` as well? It'll help testing when refactoring everything behind a new API.
>
>
> I wasn't sure the best way to do that initially, but thinking some more I think this is what I can do: In http://reviews.llvm.org/D19556 (individual index files) I will sink the lifetime of the raw_fd_ostream into WriteIndexToFile (similar to how it is done within EmitImportsFiles in http://reviews.llvm.org/D19636). Then I can move getOutputModulePath into FunctionImport.cpp as well, and just pass the new and old prefix into those routines and do the replacement there before opening the files.


I remembered why I didn't do this - what I describe above doesn't work since WriteIndexToFile is in the bitcode writer, and I don't want to add a dependence from it to the function importer or vice versa. It's difficult to sink the code here, which is just doing path and file operations, into the function importer since the result is used both by EmitImports (in the function importer) and for WriteIndexToFile (in the bitcode writer).

What I did instead was to extract the path manipulation done here to replace the matching path prefix with a new prefix into a new path method in libSupport (and added unit tests). I then invoke that both from gold-plugin as well as from llvm-lto. There is some code duplicated between gold-plugin and llvm-lto but it is now pretty minimal (just invoking some basic option parsing and the path support library routines). I added a companion llvm-lto test as well.


http://reviews.llvm.org/D19644