Skip to content

Upgrade CppInterOp to support llvm 20 #491

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 23 commits into
base: main
Choose a base branch
from

Conversation

mcbarton
Copy link
Collaborator

@mcbarton mcbarton commented Jan 29, 2025

Description

Please include a summary of changes, motivation and context for this PR.

Given the llvm 20.x branch got released today I can begin the upgrade to CppInterOp to support llvm 20.

Fixes # (issue)

Type of change

Please tick all options which are relevant.

  • New feature
  • Requires documentation updates

Testing

Please describe the test(s) that you added and ran to verify your changes.

Checklist

  • I have read the contribution guide recently

Copy link

codecov bot commented Jan 29, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.16%. Comparing base (721d33b) to head (780f02b).
Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #491   +/-   ##
=======================================
  Coverage   76.16%   76.16%           
=======================================
  Files           9        9           
  Lines        3655     3655           
=======================================
  Hits         2784     2784           
  Misses        871      871           
Files with missing lines Coverage Δ
lib/Interpreter/Paths.cpp 55.19% <ø> (ø)
Files with missing lines Coverage Δ
lib/Interpreter/Paths.cpp 55.19% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang-tidy made some suggestions

@@ -174,13 +174,15 @@ void CopyIncludePaths(const clang::HeaderSearchOptions& Opts,
if (!withSystem) continue;
if (withFlags) incpaths.push_back("-isystem");
break;

//option doesn't appear to exist for llvm>19. Will revert if I determine otherwise.
#if CLANG_VERSION_MAJOR < 20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warning: no header providing "CLANG_VERSION_MAJOR" is directly included [misc-include-cleaner]

lib/Interpreter/Paths.cpp:20:

+ #include <clang/Basic/Version.h>

@mcbarton mcbarton force-pushed the Update-to-llvm-20 branch 4 times, most recently from c8a5a4d to e435205 Compare February 2, 2025 21:22
@mcbarton mcbarton changed the title [wip] Upgrade CppInterOp to support llvm 20. Upgrade CppInterOp to support llvm 20 (non-wasm) Feb 3, 2025
@mcbarton mcbarton marked this pull request as ready for review February 3, 2025 21:23
@mcbarton mcbarton requested a review from vgvassilev February 3, 2025 21:23
@anutosh491
Copy link
Collaborator

anutosh491 commented Feb 4, 2025

I get these warnings while building latest llvm

CMake Deprecation Warning at /Users/anutosh491/work/llvm-project/clang/CMakeLists.txt:444 (message):
  'CLANG_ENABLE_ARCMT' is deprecated as ARCMigrate has been removed from
  Clang.  Please use 'CLANG_ENABLE_OBJC_REWRITER' instead to enable or
  disable the Objective-C rewriter.
  

Possibly should be fixed in our llvm build too !

@mcbarton
Copy link
Collaborator Author

mcbarton commented Feb 4, 2025

I get these warnings while building latest llvm

CMake Deprecation Warning at /Users/anutosh491/work/llvm-project/clang/CMakeLists.txt:444 (message):
  'CLANG_ENABLE_ARCMT' is deprecated as ARCMigrate has been removed from
  Clang.  Please use 'CLANG_ENABLE_OBJC_REWRITER' instead to enable or
  disable the Objective-C rewriter.
  

Possibly should be fixed in our llvm build too !

Thanks. Will look into this. Need to see if this option is avilable on older versions of llvm, given the ci covers multiple versions.

@anutosh491
Copy link
Collaborator

Hi,

Just curious as to what work is left here (as llvm 20.0.1 was released last week) ?
And it is there something specific requirement that we only handle "non-wasm" through this PR ?

@mcbarton
Copy link
Collaborator Author

Hi,

Just curious as to what work is left here (as llvm 20.0.1 was released last week) ? And it is there something specific requirement that we only handle "non-wasm" through this PR ?

@anutosh491 This PR is simply waiting for review and approval. I wasn't expecting the release last week, so that is why I didn't request a review yet (I thought it was this week). I only just realised it got released today. The reason its only covering non-wasm is because I can't get an Emscripten build of llvm 20 to work. I was planning to ask if you had had any luck compiling.

@vgvassilev can you review this PR?

@anutosh491
Copy link
Collaborator

anutosh491 commented Mar 11, 2025

Yeah someone else told me too that getting an emscripten build for llvm is tough. I haven't tried it yet and shall give it an attempt!

Edit: out of curiosity, I guess it makes sense to keep the latest possible plvm versions used for wasm and non-wasm the same. Does it ?

I'll try to get a working wasm build with llvm 20 asap if that's case (I didn't realise it was this tough)

@anutosh491
Copy link
Collaborator

anutosh491 commented Mar 12, 2025

Hi @mcbarton

I was trying to get a wasm build for latest upstream llvm this morning and these were the only two things I found concerning.

  1. When you start building the first error expected is this
 │ │ In file included from $SRC_DIR/llvm/lib/Frontend/OpenACC/ACC.cpp:9:
 │ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:1: error: unknown type name 'LLVM_ABI'
 │ │   192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
 │ │       | ^
 │ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:19: error: expected ';' after top level declarator
 │ │   192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
 │ │       |                   ^

Can also be seen here through my build on emscripten-forge.

Now this was happening because we weren't defining LLVM_ABI correctly when building against emscripten. If you see llvm/Support/Compiler.h, the condition only checked for the platform __WASM__ . Now Emscripten targets WebAssembly but doesn't imply the platform by default so the check isn't complete to define LLVM_ABI. So I added a patch to address this for now.

  1. There was an error creating the TargetMachine for creating the wasm modules while running clang-repl in the browser. That was fixed by [clang-repl] Fix target creation in Wasm.cpp llvm/llvm-project#130909 (merged)

So we should be good to have a wasm build for llvm.

The build was successful and I also tried it with my pet project

image

@@ -54,7 +57,12 @@ TEST(CUDATest, Sanity) {
EXPECT_TRUE(Cpp::CreateInterpreter({}, {"--cuda"}));
}

#if CLANG_VERSION_MAJOR == 20
// FIXME: CUDA Tests Broken for llvm 20 release/
TEST(DISABLED_CUDATest, CUDAH) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably figure out what's going on here before moving forward.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vgvassilev This is the error with the CudaTests trying to run with an llvm 20 build https://github.com/compiler-research/CppInterOp/actions/runs/13820931151/job/38668593188?pr=491#step:10:187 . Any ideas about what is going on, or how to fix it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anutosh491 @aaronj0 @Vipul-Cariappa any ideas about what is happening to cause the above error message in the native build, or how to debug it?

@anutosh491
Copy link
Collaborator

anutosh491 commented Mar 18, 2025

With respect to this

#491 (comment)

Both my PRs required to for building latest llvm against emscripten were merged. I had added one as a patch on emscripten-forge but that's merged too, so hopefully we should be fine after the next release (this one llvm/llvm-project#131578)

So hopefully moving for llvm 20 for the emscripten use case isn't an issue now ;)

@mcbarton
Copy link
Collaborator Author

With respect to this

#491 (comment)

Both my PRs required to for building latest llvm against emscripten were merged. I had added one as a patch on emscripten-forge but that's merged too, so hopefully we should be fine after the next release (this one llvm/llvm-project#131578)

So hopefully moving for llvm 20 for the emscripten use case isn't an issue now ;)

@anutosh491 Your cherry pick command in the llvm PR failed (see llvm/llvm-project#131578 (comment) ). You may need to try again.

@anutosh491
Copy link
Collaborator

With respect to this
#491 (comment)
Both my PRs required to for building latest llvm against emscripten were merged. I had added one as a patch on emscripten-forge but that's merged too, so hopefully we should be fine after the next release (this one llvm/llvm-project#131578)
So hopefully moving for llvm 20 for the emscripten use case isn't an issue now ;)

@anutosh491 Your cherry pick command in the llvm PR failed (see llvm/llvm-project#131578 (comment) ). You may need to try again.

Hey @vgvassilev could you help us here by applying the required milestone on the PR so that the cherry pick passes ?

@anutosh491
Copy link
Collaborator

Hey @mcbarton

I was interested in knowing if you were able to figure out what blocks this PR ?
Also I am not sure a separate PR would be need for llvm 20 for wasm cases ?
If yes, I think I should have all tools to make that happen. Please let me know if that's something I should do but again I am guessing updating both cases together would make more sense !

Asking this cause llvm 20.1.2 was out today (llvm 20 being out quite some time ago) and would be great if we could make the move soon and also probably a release supporting latest llvm too.

@mcbarton
Copy link
Collaborator Author

mcbarton commented Apr 2, 2025

Hey @mcbarton

I was interested in knowing if you were able to figure out what blocks this PR ? Also I am not sure a separate PR would be need for llvm 20 for wasm cases ? If yes, I think I should have all tools to make that happen. Please let me know if that's something I should do but again I am guessing updating both cases together would make more sense !

Asking this cause llvm 20.1.2 was out today (llvm 20 being out quite some time ago) and would be great if we could make the move soon and also probably a release supporting latest llvm too.

Hi @anutosh491 With the changes you've made to llvm I plan to make this PR add jobs for both native and Emscripten llvm 20 cases. The only blocker for this PR is the error mentioned in this comment #491 (comment) . Any ideas what is going on?

@anutosh491
Copy link
Collaborator

anutosh491 commented Apr 2, 2025

Any ideas what is going on?

Hmm, can give it a look as I find time.

@mcbarton mcbarton changed the title Upgrade CppInterOp to support llvm 20 (non-wasm) Upgrade CppInterOp to support llvm 20 Apr 3, 2025
@mcbarton
Copy link
Collaborator Author

While investigating the failing CUDA test locally I noticed the following. If I run clang-repl version 19 and 20 locally on MacOS I get (obviously not expecting to work given MacOS doesn't support Nvidia gpus, but it is interesting to note that version 20 crashes with a segmentation fault with the CUDA flag)

CppInterOp ->clang-repl-mp-19 --cuda
clang-repl: dlopen(libcudart.so, 0x0009): tried: 'libcudart.so' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibcudart.so' (no such file), '/opt/local/libexec/llvm-19/lib/../lib/libcudart.so' (no such file), '/opt/local/libexec/llvm-19/bin/../lib/libcudart.so' (no such file), '/usr/lib/libcudart.so' (no such file, not in dyld cache), 'libcudart.so' (no such file)
CppInterOp ->clang-repl-mp-20 --cuda
#0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc)
#1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc)
#2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628)
#3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4)
#4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8)
#7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8)
#8 0x000000019ae8c274 
Segmentation fault: 11

Running clang-repl version 20 with the cuda flag on Ubuntu also has a segmentation fault

image

I absolutely could be wrong, but this at least to me suggests that fixing the test may require a change in llvm. I'm not well versed on how llvm is handling anything related to cuda. @vgvassilev can you provide me with some insight, or cc someone who may be able to help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants