Skip to content

RuntimeLibcalls: Account for Triple default exception handling #147224

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

Conversation

arsenm
Copy link
Contributor

@arsenm arsenm commented Jul 7, 2025

Previously we were taking the raw TargetOptions exception mode.
This only works correctly for the TargetLowering usage, when
the -exception-model flag is explicitly used.

The interface isn't great, and interprets none to both mean use
target default and unsupported, such that it's not possible to
opt-out of exceptions on targets that report a non-none default.

We also still get the wrong mode in the linker usecase of
RuntimeLibcalls since it doesn't have the TargetMachine. But at
least wrongly being the default is an improvement over being unset.

I'm not really sure how to write a test for this.

@llvmbot
Copy link
Member

llvmbot commented Jul 7, 2025

@llvm/pr-subscribers-llvm-ir

Author: Matt Arsenault (arsenm)

Changes

Previously we were taking the raw TargetOptions exception mode.
This only works correctly for the TargetLowering usage, when
the -exception-model flag is explicitly used.

The interface isn't great, and interprets none to both mean use
target default and unsupported, such that it's not possible to
opt-out of exceptions on targets that report a non-none default.

We also still get the wrong mode in the linker usecase of
RuntimeLibcalls since it doesn't have the TargetMachine. But at
least wrongly being the default is an improvement over being unset.

I'm not really sure how to write a test for this.


Full diff: https://github.com/llvm/llvm-project/pull/147224.diff

1 Files Affected:

  • (modified) llvm/include/llvm/IR/RuntimeLibcalls.h (+8)
diff --git a/llvm/include/llvm/IR/RuntimeLibcalls.h b/llvm/include/llvm/IR/RuntimeLibcalls.h
index 50b9791111ce2..9470d22bcad31 100644
--- a/llvm/include/llvm/IR/RuntimeLibcalls.h
+++ b/llvm/include/llvm/IR/RuntimeLibcalls.h
@@ -53,6 +53,14 @@ struct RuntimeLibcallsInfo {
       EABI EABIVersion = EABI::Default, StringRef ABIName = "") {
     initSoftFloatCmpLibcallPredicates();
     initDefaultLibCallImpls();
+
+    // FIXME: The ExceptionModel parameter is to handle the field in
+    // TargetOptions. This interface fails to distinguish the forced disable
+    // case for targets which support exceptions by default. This should
+    // probably be a module flag and removed from TargetOptions.
+    if (ExceptionModel == ExceptionHandling::None)
+      ExceptionModel = TT.getDefaultExceptionHandling();
+
     initLibcalls(TT, ExceptionModel, FloatABI, EABIVersion, ABIName);
   }
 

Copy link
Member

@DanielKristofKiss DanielKristofKiss left a comment

Choose a reason for hiding this comment

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

reasonable, anyway the right solution is to derive it from the module attributes or such.

@arsenm
Copy link
Contributor Author

arsenm commented Jul 7, 2025

I somehow submitted these in the wrong order, #147225 should be first

@arsenm arsenm force-pushed the users/arsenm/runtime-libcalls/set-default-exception-handling-from-triple branch from dc7ce29 to a0a9fd6 Compare July 7, 2025 15:33
Copy link
Contributor

@dpaoliello dpaoliello left a comment

Choose a reason for hiding this comment

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

LGTM

@dpaoliello
Copy link
Contributor

If you don't already have plans to fix this, could you please file an issue?

@arsenm arsenm force-pushed the users/arsenm/runtime-libcalls/set-default-exception-handling-from-triple branch from a0a9fd6 to e5a1556 Compare July 8, 2025 00:59
Previously we were taking the raw TargetOptions exception mode.
This only works correctly for the TargetLowering usage, when
the -exception-model flag is explicitly used.

The interface isn't great, and interprets none to both mean use
target default and unsupported, such that it's not possible to
opt-out of exceptions on targets that report a non-none default.

We also still get the wrong mode in the linker usecase of
RuntimeLibcalls since it doesn't have the TargetMachine. But at
least wrongly being the default is an improvement over being unset.

I'm not really sure how to write a test for this.
@arsenm arsenm force-pushed the users/arsenm/runtime-libcalls/set-default-exception-handling-from-triple branch from e5a1556 to 4063247 Compare July 8, 2025 04:05
@arsenm
Copy link
Contributor Author

arsenm commented Jul 8, 2025

If you don't already have plans to fix this, could you please file an issue?

That's at least 3 steps away. First need to split the lowering decisions from the set of libcalls, and then turn RuntimeLibcalls into an analysis, then replace the TargetOptions field with a module flag

@arsenm arsenm merged commit 32f461b into main Jul 8, 2025
8 of 9 checks passed
@arsenm arsenm deleted the users/arsenm/runtime-libcalls/set-default-exception-handling-from-triple branch July 8, 2025 04:39
@llvm-ci
Copy link
Collaborator

llvm-ci commented Jul 9, 2025

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-expensive-checks-debian running on gribozavr4 while building llvm at step 6 "test-build-unified-tree-check-all".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/16/builds/22256

Here is the relevant piece of the build log for the reference
Step 6 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM :: TableGen/RuntimeLibcallEmitter-conflict-warning.td' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llvm-tblgen -gen-runtime-libcalls -I /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/../../include /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td 2> /b/1/llvm-clang-x86_64-expensive-checks-debian/build/test/TableGen/Output/RuntimeLibcallEmitter-conflict-warning.td.tmp.err | /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td # RUN: at line 1
+ /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llvm-tblgen -gen-runtime-libcalls -I /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/../../include /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td
+ /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td
/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td:29:16: error: CHECK-NEXT: is not on the line after the previous match
// CHECK-NEXT: {RTLIB::SOME_FUNC, RTLIB::func_b}, // func_b
               ^
<stdin>:98:2: note: 'next' match was here
 {RTLIB::SOME_FUNC, RTLIB::func_b}, // func_b
 ^
<stdin>:72:49: note: previous match ended here
 static const LibcallImplPair LibraryCalls[] = {
                                                ^
<stdin>:73:1: note: non-matching line after previous match is here
 {RTLIB::SOME_FUNC, RTLIB::func_a}, // func_a
^

Input file: <stdin>
Check file: /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/TableGen/RuntimeLibcallEmitter-conflict-warning.td

-dump-input=help explains the following input dump.

Input was:
<<<<<<
         .
         .
         .
        93:  
        94:  if (isTargetArchC()) { 
        95:  static const LibcallImplPair LibraryCalls[] = { 
        96:  {RTLIB::ANOTHER_DUP, RTLIB::dup0}, // dup0 
        97:  {RTLIB::OTHER_FUNC, RTLIB::other_func}, // other_func 
        98:  {RTLIB::SOME_FUNC, RTLIB::func_b}, // func_b 
next:29      !~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  error: match on wrong line
        99:  }; 
       100:  
       101:  for (const auto [Func, Impl] : LibraryCalls) { 
       102:  setLibcallImpl(Func, Impl); 
       103:  } 
         .
         .
         .
>>>>>>

--

...

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

Successfully merging this pull request may close these issues.

5 participants