[all-commits] [llvm/llvm-project] 3a4d8a: [Clang] Stop using strip.invariant.group (#225072)
Nikita Popov via All-commits
all-commits at lists.llvm.org
Tue Sep 22 00:26:46 PDT 2026
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 3a4d8a9e6acaed193477208328be0eb8f24fd253
https://github.com/llvm/llvm-project/commit/3a4d8a9e6acaed193477208328be0eb8f24fd253
Author: Nikita Popov <npopov at redhat.com>
Date: 2026-09-22 (Tue, 22 Sep 2026)
Changed paths:
M clang/lib/CodeGen/CGBuilder.h
M clang/lib/CodeGen/CGExpr.cpp
M clang/lib/CodeGen/CGExprScalar.cpp
M clang/test/CodeGenCXX/strict-vtable-pointers.cpp
Log Message:
-----------
[Clang] Stop using strip.invariant.group (#225072)
Clang currently emits calls to llvm.strip.invariant.group under
`-fstrict-vtable-pointers` whenever a pointer to a dynamic object is
used in a comparison or might be used in a comparison through operations
we cannot track.
The purpose of the llvm.strip.invariant.group intrinsic is to make sure
that if we have a dominating condition like `a ==
launder.invariant.group(a)`, we don't end up replacing the latter with
the former, as that would allow the optimizer to assume that the memory
stays invariant, despite going through a launder operation (e.g. on
placement new).
However, since this was introduced, we've come to the understanding that
replacing pointers based on equality comparison is generally only legal
if they have the same provenance, and stopped doing such replacements.
The specific strip.invariant.group/launder.invariant.group case was
still buggy due to an implementation bug, but this was fixed in
https://github.com/llvm/llvm-project/pull/224281.
As such, I believe that we no longer need to emit
llvm.strip.invariant.group in Clang. I plan to also remove the LLVM
intrinsic in a followup.
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list