Recent upstream LLVM changes enabled `LoopInterchangePass` by default through `PipelineTuningOptions`. TLTO observes that state directly from the LTO config, but DTLTO was not forwarding the equivalent Clang option to the remote compiler. As a result, TLTO could run loop interchange pass while DTLTO did not, producing codegen differences for configurations that exposed profitable/legally interchangeable loops. Note that this was a pre-existing issue, the change in default has simply exposed it. Forward `C.PTO.LoopInterchange` as `-floop-interchange` when constructing the common DTLTO remote compiler options. Extend the testing to check that the SN-DBS remote command line includes the forwarded option. The code for forwarding such options is only intended as a temporary measure. A more comprehensive solution is in discussion here: https://discourse.llvm.org/t/synchronizing-lto-code-generation-configuration-between-clang-and-lld-dtlto |
||
|---|---|---|
| .. | ||
| archive.test | ||
| archives-mixed-lto-modes-test.test | ||
| archives-same-module-id.test | ||
| cache-extraction.test | ||
| dtlto-cache.test | ||
| dtlto-thinlto-cache.test | ||
| fat-lto-objects.test | ||
| ld-archive-thin.test | ||
| ld-dtlto.c | ||
| link-archive-thin.test | ||
| link-dtlto.c | ||
| link-savetemps.test | ||
| lit.local.cfg | ||
| local_codegen_and_wait.py | ||
| multimodule.test | ||
| path.test | ||
| README.md | ||
| remote-options.test | ||
| savetemps-lock.test | ||
| savetemps.test | ||
| signal.test | ||
| test_temps.py | ||
| unicode.test | ||
Tests for DTLTO (Integrated Distributed ThinLTO) functionality.
These are integration tests as DTLTO invokes clang for code-generation.