Dec 10 2021
Applied pcc's changes.
Dec 9 2021
Based on more offline feedback from pcc, moved the conditional assignment handling from MCStreamer to MCObjectStreamer. This allows us to drop the emittedSymbols set as MCAssembler already keeps track of the symbols. As MCAsmStreamer now passes through the .lto_set_conditional directives, changed the tests to look at the generated objects instead.
Dec 3 2021
Changed the key of the pendingAssignments map to const MCSymbol * and switched from StringMap/Set to DenseMap/Set based on feedback from pcc.
Dec 1 2021
Nov 29 2021
Use standard l-value conversions, and add a test case for constexpr.
Nov 24 2021
Your builtin is using custom type-checking (t), which suppresses all the normal conversions that happen on expressions. Specifically, it skips lvalue-to-rvalue conversion, so in this example the argument ends up being an l-value reference to a variable rather than an r-value loaded from that variable.
Nov 23 2021
Changed the code to evaluate the argument as a constant expression.
I worked around this for now by explicitly allowing __builtin_function_start in CheckLValueConstantExpression, but this seems terribly hacky. What would be the correct way to solve this issue?
Try to generalize what we do for __builtin___CFStringMakeConstantString.
Sure, I can take a look at how that would work. Basically, in PointerExprEvaluator::VisitBuiltinCallExpr we should not evaluate the l-value and just leave it at Result.set(E)?
Yes, exactly. Since the builtin already requires a constant operand in non-dependent contexts, that should be enough.
Refactored to avoid evaluating the expression into an l-value.
Nov 19 2021
Renamed to .lto_set_conditional.
Updated tests to use # and reordered the CHECKs for clarity.
Nov 18 2021
Renamed to __builtin_function_start, allowed only FunctionDecls as a parameter, added support for C++ member functions, and disallowed comparisons in integral constant expressions.
Nov 17 2021
Added a MachO test to ensure we emit .no_dead_strip correctly.
Nov 16 2021
Addressed Nick's comments: Switched to StringSet, preserved MCSA_NoDeadStrip, made the code more DRY.
Nov 10 2021
Here's an alternative solution to the code bloat problem caused by promotion aliases, based on pcc's suggestion. This works with the kernel and nacl_helper size is back to normal in Chrome. Please let me know if you see issues with this approach.
Nov 5 2021
You could also make this Just Work for things like C++ member functions rather than producing a member function pointer.
Nov 4 2021
Keep a void * return type for the nocfi variant.
Oct 29 2021
Missed a comment.
Addressed pcc's comments.
Oct 28 2021
Oct 15 2021
I tested the latest version with a CFI kernel build, and everything still looks good. I see the same number of .cfi_jt symbols with ThinLTO and full LTO.
Oct 5 2021
Fixed bitcast handling in NoCFIValue::handleOperandChangeImpl.
Sep 9 2021
causes confusing stack traces in applications
Aug 31 2021
Fixed clang-tidy warnings, dropped an unnecessary auto.
I think you might want to update the syntax files for the various text editors. See:
Fixed clang-tidy warnings, cleaned up tests.
Aug 20 2021
Here's a PoC of the built-in function that returns the address of the function body with CFI. Based on D108478.
Here's a PoC of the "no cfi" constant type suggested by Peter. PTAL.
Aug 18 2021
Aug 12 2021
Thanks, Nick. I tested a kernel build with both ThinLTO and regular LTO + CFI, and can confirm that with this patch vmlinux has the previously missing .cfi_jt symbols again.
Aug 3 2021
Jul 30 2021
Also skip functions with names incompatible with XCOFF.
Jul 21 2021
As we only care about fixing inline assembly references, mangled names are
not that important in the first place. This version skips any functions
that have unusual characters in their names that would otherwise require
quotes, which includes any functions with MSVC compatible name mangling.
Jul 20 2021
Folded in D106392.
Nick suggested reverting until we figure out if this is the ideal fix here. I'll fold this to the original patch.
This patch broke the sanitizer-windows bot: https://lab.llvm.org/buildbot/#/builders/127/builds/14257Failed Tests (4): cfi-devirt-lld-thinlto-x86_64 :: anon-namespace.cpp cfi-devirt-lld-thinlto-x86_64 :: simple-pass.cpp cfi-standalone-lld-thinlto-x86_64 :: anon-namespace.cpp cfi-standalone-lld-thinlto-x86_64 :: simple-pass.cpp
Please revert or fix.
Jul 16 2021
Added REQUIRES: x86-registered-target to tests.
The tests that now specify a target triple also need ; REQUIRES: x86-registered-target or they will obviously fail. I'll upload another revision.
I'm curious if this will lead to breakages with LTO in general? I suppose not, since it's llvm-lto2 that needs the explicit list of symbols that can be linked against.
Jul 14 2021
Change LGTM, but I don't understand why the following tests are modified:
Jul 13 2021
Moved the alias creation to module level inline assembly to avoid issues with LowerTypeTestsModule, based on pcc's suggestion.
Jun 23 2021
Thanks for the revert, I'll take a look.
Jun 22 2021
Fix a use-of-uninitialized-value error.
Jun 17 2021
Moved the test to llvm/test/Transforms/ThinLTOBitcodeWriter.
Jun 10 2021
Changed the message to refer to CallBase instead of CallInst.
Thanks, Nick. I don't have commit access, so would you mind committing the patch? I confirmed that check-all passes for me with the patch applied.
Jun 8 2021
Thanks, Peter. I don't have commit access, so Nick, would you mind committing this for me? The Windows build failure looks unrelated.