aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/ModuloSchedule.cpp
diff options
context:
space:
mode:
authorChuanqi Xu <yedeng.yd@linux.alibaba.com>2024-03-17 21:14:53 +0800
committerGitHub <noreply@github.com>2024-03-17 21:14:53 +0800
commit0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7 (patch)
treee697512b9b0521c9cde93885d2e002de5f5205d5 /llvm/lib/CodeGen/ModuloSchedule.cpp
parent0269790c9894aaf882b939a6802aa3501d610b3c (diff)
downloadllvm-0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7.zip
llvm-0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7.tar.gz
llvm-0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7.tar.bz2
Reland Print library module manifest path again (#84881)
Following of https://github.com/llvm/llvm-project/pull/82160 The reason why the above PR fails is that the `--sysroot` has lower priority than the libc++ built from the same source. On the one hand, it matches the codes behavior. We will add the built libc++ project paths in the ToolChain class. But we will only add the path related to sysroot in Linux class, which is derived from the ToolChain classes. So the paths of just built libc++ is in the front of the paths relative to sysroot. On the other hand, the behavior should be good from the higher level. Since the just built libc++ has the same version number with the just built clang, so it makes sense that these 2 compilers just matches. So for patch it self, I hacked it by using resource dir in the test since the resource dir has the higher priority, which is not strongly correct since we won't do that in practice. @kaz7 would you like to test on your environment to avoid this get reverted again? On the libc++ side, it shows that it lacks a `modules.json` file for the just built libc++ directory. If we don't have that, it will be problematic to use std modules from the just built clang and libc++ pair. Then it is not good. And I feel it may be problematic for future compiler/standard library developers. So I feel this is somewhat a libc++ issue that need to be fixed. Also if we don't like the hacked test in the current patch, we must wait for libc++ to fix this to proceed. But I feel this is somewhat odd since the test of clang shouldn't dependent on libc++. CC: @mordante --------- Co-authored-by: Mark de Wever <koraq@xs4all.nl>
Diffstat (limited to 'llvm/lib/CodeGen/ModuloSchedule.cpp')
0 files changed, 0 insertions, 0 deletions