[compiler-rt] [llvm] [ThinLTO][TypeProf] Import local-linkage global var for mod1:func_foo-> mod2:local-var edge (PR #100448)

[Mingming Liu via llvm-commits]

================
@@ -174,6 +174,17 @@ static cl::opt<std::string> WorkloadDefinitions(
              "}"),
     cl::Hidden);
 
+static cl::opt<bool> ImportAssumeUniqueLocal(
+    "import-assume-unique-local", cl::init(false),
+    cl::desc(
+        "By default, a local-linkage global variable won't be imported in the "
+        "edge mod1:func -> mod2:local-var (from value profiles) since compiler "
+        "cannot assume mod2 is compiled with full path which gives local-var a "
+        "program-wide unique GUID. Set this option to true will help cross "
+        "module import of such variables. This is only safe if the compiler "
----------------
minglotus-6 wrote:

> How does user specify it?

In a monolithic repository (https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/) of source code, user specifies the full path in the compile options.

Using the folder structure below as an example [1], `clang -O2 <other-options> /tmp/src1/a.cpp /tmp/src1/b.cpp /tmp/src2/a.cpp /tmp/src2/b.cpp /tmp/src2/c.cpp` gives the full path, and `cd /tmp/src1; clang -O2 a.cpp b.cpp <other arguments to specify paths in src2>` doesn't.

In practice, bazel (https://bazel.build/) configures the build rules and guarantees full path is used. Users use bazel to compile an executable.

>  I looked at the test and it's not clear to me from it.

The purpose of the test is to illustrate and provide coverage for profile-gen and its use, so I saved the extra work to use full path there.

[1]
```
/tmp/
|── src1/
│   ├── a.cpp
│   ├── b.cpp
├── src2/
│   ├── a.cpp
│   ├── b.cpp
│   └──c.cpp
```

https://github.com/llvm/llvm-project/pull/100448