@@ -14918,52 +14918,57 @@ void Sema::CheckCompleteVariableDeclaration(VarDecl
*var) {
}
// Apply section attributes and pragmas to global variables.
- if (GlobalStorage && var->isThisDeclarationADefinition() &&
- !inTemplateInstantiation()) {
-PragmaStack *Stack
efriedma-quic wrote:
I think the current state addresses my concerns, yes. I'd like to make one
final pass over it, though; please git-clang-format and rebase the patch.
https://github.com/llvm/llvm-project/pull/78707
___
cfe-commits mailing list
cfe
@@ -3679,6 +3679,35 @@ the arguments. Both arguments and the result have the
bitwidth specified
by the name of the builtin. These builtins can be used within constant
expressions.
+``__builtin_stdc_rotate_left`` and ``__builtin_stdc_rotate_right``
+---
efriedma-quic wrote:
For very old clang code, we were less rigorous about test checks; these days
we'd very rarely approve -emit-llvm-only tests. Especially since we have
update_cc_test_checks.py.
It probably makes sense to change the test to an update_cc_test_checks.py test,
just so nobody
@@ -3642,6 +3642,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
case Builtin::BI__builtin_rotateleft16:
case Builtin::BI__builtin_rotateleft32:
case Builtin::BI__builtin_rotateleft64:
+ case Builtin::BI__builtin_stdc_rotate_left:
-
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/156643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
If you want me to merge for you, please let me know.
https://github.com/llvm/llvm-project/pull/158424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/158424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Why do we want to run sanitizer passes prelink? Wouldn't it be more effective
to run them postlink?
https://github.com/llvm/llvm-project/pull/160213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/155829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
There's a corresponding intrinsic llvm.fake.use (FAKE_USE in MIR), which isn't
used by anything else. Possibly there's a bug in the implementation of that
intrinsic.
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commi
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/156643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/156643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -405,6 +405,7 @@ void CodeGenFunction::FinishFunction(SourceLocation EndLoc)
{
// parameters. Do this in whatever block we're currently in; it's
// important to do this before we enter the return block or return
// edges will be *really* confused.
+
efriedma-quic wrote:
In any context where the standard requires constant evaluation, we have to
return false, probably. (This corresponds, roughly, to Info.InConstantContext.
I don't think we have a bit that precisely corresponds, though.)
We probably do want to fold in tryEvaluateObjectSize
@@ -3011,6 +3016,37 @@ void CodeGenModule::ConstructAttributeList(StringRef
Name,
}
assert(ArgNo == FI.arg_size());
+ ArgNo = 0;
+ if (AddedPotentialArgAccess && MemAttrForPtrArgs) {
+llvm::SmallSet ArgsToSkip;
+if (IRFunctionArgs.hasSRetArg()) {
+ ArgsToSk
efriedma-quic wrote:
Try the following with -std=c++23 -Winvalid-constexpr:
```
constexpr int f(int &a) {
return 1 / (__builtin_object_size(&a, 0) - 4);
}
int a[2];
static_assert(f(a[0]) == 0);
```
https://github.com/llvm/llvm-project/pull/157778
__
@@ -348,6 +350,76 @@ entry:
ret i32 %call
}
+declare i32 @test_explicit_priority._Mmops() #18
+declare i32 @test_explicit_priority._Msve2() #19
+declare i32 @test_explicit_priority._Msve() #20
+declare i32 @test_explicit_priority.default() #0
+
+define weak_odr ptr @test_exp
https://github.com/efriedma-quic commented:
LGTM
https://github.com/llvm/llvm-project/pull/157925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/156440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
Can you unify the test with clang/test/CodeGen/PowerPC/ppc-sfvarargs.c, since
it's testing basically the same thing?
https://github.com/llvm/llvm-project/pull/154773
___
cfe-commits mailing list
cfe-commits@
@@ -1,15 +1,17 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 6
// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future \
efriedma-quic wrote:
I don't have time to look more now... but please do an extra pass and call out
any tests with potentially interesting changes.
https://github.com/llvm/llvm-project/pull/154347
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
efriedma-quic wrote:
> Since there are multiple store operations to immutable alloca here, the
> optimization will conservatively not be performed at all.
In the trivial case I showed, you can find all the stores. More generally,
other optimizations can hide stores, so iterating over the use
efriedma-quic wrote:
Deferencing a pointer, __builtin_memcpy, and most other operations that involve
accessing pointers, currently assume pointers are naturally aligned. The exact
representation of this in LLVM IR varies, but the fundamental assumption is
that you're following normal C/C++ st
@@ -1,15 +1,17 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 6
// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future \
efriedma-quic wrote:
Consider:
```
void f(int*);
void g() {
for (int i = 0; i < 10; ++i) {
const int j = i;
f(&j);
}
}
```
There's "one store"... but consider what happens if the loop is unrolled.
-
There's also more subtle issues; we don't guarantee "one store" actually
rema
https://github.com/efriedma-quic commented:
This is roughly what I expected. But it looks like there are some build
failures on the bot.
https://github.com/llvm/llvm-project/pull/156643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
https://github.com/efriedma-quic commented:
Instead of creating a separate cleanup stack and adding special deferred
handling for that cleanup stack, can we just skip creating the scope in the
first place? We have `LexicalScope ForScope(*this, S.getSourceRange());`; can
we replace that with s
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/141573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Given the current definition of "ninf", there is no way to legally check if a
value produced by an "ninf" instruction is infinity: even if the bitpattern
looks like an infinity, it's actually poison. If that's causing problems for
you, we might need to revisit the definit
https://github.com/efriedma-quic approved this pull request.
I've reviewed other changes here recently (#152866). The code is playing some
weird games with memory allocation, using an std::vector as an arena. Probably
there's some better way to write this. Strictly speaking, it's undefined
https://github.com/efriedma-quic commented:
"End of the function" is not really correct. It's still the end of the scope...
just the scope in question is different. This matters if you have, for
example, a nested loop.
Probably need to change CodeGenFunction::EmitForStmt to push the scope at
@@ -275,10 +276,14 @@ SparcV9ABIInfo::classifyType(QualType Ty, unsigned
SizeLimit) const {
// Try to use the original type for coercion.
llvm::Type *CoerceTy = CB.isUsableType(StrTy) ? StrTy : CB.getType();
+ // We use a pair of i64 for 9-16 byte aggregate with 8 byte a
https://github.com/efriedma-quic commented:
Is there some reason clang can't just generate a call to `llvm.is.fpclass`?
https://github.com/llvm/llvm-project/pull/156570
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/151053
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Sorry, forgot this was still open.
https://github.com/llvm/llvm-project/pull/151053
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/151053
>From 43e441c0559294f0e4d85cf67bea480140b2e9d1 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Mon, 28 Jul 2025 15:47:33 -0700
Subject: [PATCH 1/2] [clang] Followup for constexpr-unknown potential consta
@@ -1480,6 +1480,14 @@ class DeclRefExpr final
return DeclRefExprBits.IsImmediateEscalating;
}
+ bool isOverflowBehaviorDiscarded() const {
efriedma-quic wrote:
I guess that makes sense. But the number of bits we have available in Expr is
really limi
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/152411
>From 9b8fdaf87ceb1478e5c4a0324de99b5ce375b175 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 6 Aug 2025 16:31:03 -0700
Subject: [PATCH 1/2] [Arm64EC][clang] Implement varargs support in clang.
Th
@@ -550,6 +550,39 @@ explicit ``overflow_behavior`` attribute.
// [-Wimplicit-overflow-behavior-conversion-pedantic]
}
+Format String Functions
+===
+
+When overflow behavior types are used with format string functions
(printf-famil
@@ -12504,6 +12514,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType
T, SourceLocation CC,
IntRange TargetRange = IntRange::forTargetOfCanonicalType(Context, Target);
if (LikelySourceRange->Width > TargetRange.Width) {
+// Check if target is a wrapping OBT -
@@ -275,10 +276,14 @@ SparcV9ABIInfo::classifyType(QualType Ty, unsigned
SizeLimit) const {
// Try to use the original type for coercion.
llvm::Type *CoerceTy = CB.isUsableType(StrTy) ? StrTy : CB.getType();
+ // We use a pair of i64 for 9-16 byte aggregate with 8 byte a
efriedma-quic wrote:
Not every inline asm, only inline asm statements that specifically have an
"unwind" clobber (or in Rust, may_unwind). Which is pretty rare, in practice:
I've never seen anyone use it in clang, and it isn't even available on stable
in Rust.
Accurately detecting whether th
@@ -0,0 +1,14 @@
+; RUN: llc < %s -mtriple=armv7 | FileCheck %s --check-prefix=armv7
+; RUN: llc < %s -mtriple=aarch64 | FileCheck %s --check-prefix=aarch64
efriedma-quic wrote:
You can't put aarch64 testcases in llvm/test/CodeGen/ARM/. They have to be in
llvm/
@@ -4248,6 +4248,39 @@ assignment can happen automatically.
to a variable, have its address taken, or passed into or returned from a
function, because doing so violates bounds safety conventions.
+.. _builtin_stack_address-doc:
+
+``__builtin_stack_address``
+-
@@ -12504,6 +12514,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType
T, SourceLocation CC,
IntRange TargetRange = IntRange::forTargetOfCanonicalType(Context, Target);
if (LikelySourceRange->Width > TargetRange.Width) {
+// Check if target is a wrapping OBT -
@@ -405,6 +405,9 @@ ArgType::matchesType(ASTContext &C, QualType argTy) const {
argTy = PT->getPointeeType();
}
+ if (const auto *OBT = argTy->getAs())
+argTy = OBT->getUnderlyingType();
efriedma-quic wrote:
Probably the documentation should mentio
@@ -3189,16 +3227,21 @@ ScalarExprEmitter::EmitScalarPrePostIncDec(const
UnaryOperator *E, LValue LV,
// Note that signed integer inc/dec with width less than int can't
// overflow because of promotion rules; we're just eliding a few steps
// here.
-} els
@@ -1480,6 +1480,14 @@ class DeclRefExpr final
return DeclRefExprBits.IsImmediateEscalating;
}
+ bool isOverflowBehaviorDiscarded() const {
efriedma-quic wrote:
Is there some description of what this bit is supposed to mean? As far as I
can tell, it
@@ -199,6 +233,19 @@ static bool CanElideOverflowCheck(const ASTContext &Ctx,
const BinOpInfo &Op) {
if (!Op.mayHaveIntegerOverflow())
return true;
+ const UnaryOperator *UO = dyn_cast(Op.E);
+ if (UO && Ctx.isUnaryOverflowPatternExcluded(UO))
+return true;
+
+ c
@@ -14389,6 +14389,36 @@ Semantics:
Note this intrinsic is only verified on AArch64 and ARM.
+'``llvm.stackaddress``' Intrinsic
+^
+
+Syntax:
+"""
+
+::
+
+ declare ptr @llvm.stackaddress()
+
+Overview:
+"
+
+The '``llvm.stacka
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/148281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
The backend code looks like what I expect. Needs a backend regression test for
some non-SPARC target.
https://github.com/llvm/llvm-project/pull/148281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
My understanding of deferred diagnostics is that the primary use is to allow
including headers that contain inline functions, and don't properly mark device
vs. host. So when you parse the function, it's unknown whether the function is
actually going to be used, which wou
@@ -11045,10 +11045,6 @@ bool RecordExprEvaluator::VisitCXXConstructExpr(const
CXXConstructExpr *E,
bool ZeroInit = E->requiresZeroInitialization();
if (CheckTrivialDefaultConstructor(Info, E->getExprLoc(), FD, ZeroInit)) {
-// If we've already performed zero-initiali
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/152575
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
Modifying the datalayout feels really strange, and I'm sort of worried it'll
have unintended consequences, especially if there's only one target doing it.
Maybe you can just skip modifying the datalayout? The passes that run after
createNVPTXLower
https://github.com/efriedma-quic approved this pull request.
I expect this doesn't have much effect in most cases; we have a bunch of
implicit conversions between vector types, so probably in most cases the vector
gets converted to the right type before anyone actually tries to use it.
LGTM
h
@@ -30,18 +30,18 @@ constexpr StringRef AssumptionAttrKey = "llvm.assume";
/// A set of known assumption strings that are accepted without warning and
/// which can be recommended as typo correction.
-LLVM_ABI extern StringSet<> KnownAssumptionStrings;
+LLVM_ABI extern StringS
@@ -160,7 +160,7 @@ inlineCostFeatureToMlFeature(InlineCostFeatureIndex
Feature) {
return static_cast(static_cast(Feature));
}
-LLVM_ABI extern std::vector FeatureMap;
+LLVM_ABI extern std::vector &getFeatureMap();
efriedma-quic wrote:
```suggestion
LLVM_A
@@ -2209,6 +2209,18 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value
*Value, Address Addr,
}
}
+ // When storing a pointer, perform address space cast if needed.
efriedma-quic wrote:
Yes, that sounds right.
https://github.com/llvm/llvm-project/
efriedma-quic wrote:
Duplicate of #152411?
https://github.com/llvm/llvm-project/pull/154578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2209,6 +2209,18 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value
*Value, Address Addr,
}
}
+ // When storing a pointer, perform address space cast if needed.
efriedma-quic wrote:
Types in IRGen should match types in the AST. So if an lvalue
efriedma-quic wrote:
git-clang-format uses the "--lines" option to clang-format restrict formatting
updates. If that isn't working correctly, please file a bug. You can ignore
the bot after that.
https://github.com/llvm/llvm-project/pull/152623
___
efriedma-quic wrote:
Oh, right, I guess x86 doesn't ever disable instructions in the assembler...
other architectures usually do. There might be other edge cases where things
get weird, like, if you do runtime CPU detection. But I don't care enough to
argue further.
Please at least leave a
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/145489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> We usually use Tuningxxx due to hardware defects, which implies some hardware
> preform good while some bad. But here the problem is we haven't fully address
> regression to make it a net profit for performance.
I don't really see a difference between the two: if there's
efriedma-quic wrote:
If we're going to explicitly add a flag for the resource dir, we should use the
flag `-resource-dir`, not try to emulate it with -I. There are other relevant
bits in the resource directory, like cfi_ignorelist.txt.
We have code in libclang which is supposed to handle this
efriedma-quic wrote:
"CF" is a hardware feature; it's incredibly confusing to just pretend it
doesn't exist because it's slow. If you need to adjust codegen, add a separate
feature TuningSlowCF or something.
https://github.com/llvm/llvm-project/pull/153751
@@ -204,8 +204,9 @@ class FullDependencyConsumer : public DependencyConsumer {
std::optional Provided,
std::vector Requires) override {
ModuleName = Provided ? Provided->ModuleName : "";
-llvm::transform(Requires, std::back_inserter(NamedModuleDeps),
-
efriedma-quic wrote:
Really, the AST design is weird: we're not supposed to do any computation when
you reference parts of the binding. We represent it as an expression just to
reduce the code required to handle bindings. As such, the set of expressions
actually allowed in a binding are quit
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/153474
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/141573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4652,6 +4659,7 @@ llvm::Constant
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
"", Resolver, &getModule());
GIF->setName(ResolverName);
SetCommonAttributes(FD, GIF);
+SetResolverAttrs(cast(Resolver));
---
https://github.com/efriedma-quic commented:
Really, I think the biggest problem with this approach is that it special-cases
compile-time casts, and treats them differently from runtime casts. That might
be just barely sufficient for specific cases from glib, but it's not
comprehensive, and it
https://github.com/efriedma-quic commented:
I'm fine with this for the branch, sure.
https://github.com/llvm/llvm-project/pull/153506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Can we just drop the check from `__has_extension` handling?
It looks like that check dates back to the introduction of __has_extension
(d5d410faa8cfbbf4e2ffc2f8aa470491a77fd843). But it's a terrible idea for a lot
of reasons: it adds a semantic effect to a flag which othe
efriedma-quic wrote:
> No, ptrauth is not a feature, it is an extension and should be reported as
> such. The real bug here is that you're missing an extension warning when
> `__ptrauth` is used
I thought our general policy was that we don't trigger pedantic warnings for
reserved keywords (li
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/152866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -132,6 +132,10 @@ class ABIInfo {
virtual llvm::FixedVectorType *
getOptimalVectorMemoryType(llvm::FixedVectorType *T,
const LangOptions &Opt) const;
+
+ /// Used by Arm64EC calling convention code to call into x86 calling
+ /// convention
@@ -1409,6 +1409,12 @@ class WinX86_64ABIInfo : public ABIInfo {
return isX86VectorCallAggregateSmallEnough(NumMembers);
}
+ ABIArgInfo classifyArgForArm64ECVarArg(QualType Ty) const override {
efriedma-quic wrote:
classifyArgForArm64ECVarArg is exclus
@@ -563,8 +563,11 @@ bool Pointer::hasSameBase(const Pointer &A, const Pointer
&B) {
if (A.isTypeidPointer() && B.isTypeidPointer())
return true;
- if (A.isIntegralPointer() || B.isIntegralPointer())
+ if (A.isIntegralPointer() || B.isIntegralPointer()) {
+if (A.i
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/151053
>From 43e441c0559294f0e4d85cf67bea480140b2e9d1 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Mon, 28 Jul 2025 15:47:33 -0700
Subject: [PATCH 1/2] [clang] Followup for constexpr-unknown potential consta
efriedma-quic wrote:
Still waiting for an answer:
> The reason I'm suspicious of the getDeclareMapperVarRef check is that
> SemaOpenMP::ActOnOMPIteratorExpr creates the variable (VarDecl::Create)
> regardless. So what's supposed to happen for variables where
> getDeclareMapperVarRef is false?
@@ -6324,10 +6324,20 @@ void
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
SetLLVMFunctionAttributesForDefinition(D, Fn);
+ auto getPriority = [this](auto *Attr) -> int {
+int priority = Attr->DefaultPriority;
+Expr *E = Attr->getPriority();
+if (
@@ -4184,29 +4184,14 @@ Value
*ScalarExprEmitter::EmitOverflowCheckedBinOp(const BinOpInfo &Ops) {
}
/// Emit pointer + index arithmetic.
-static Value *emitPointerArithmetic(CodeGenFunction &CGF,
-const BinOpInfo &op,
-
@@ -1381,6 +1432,13 @@ static Address EmitPointerWithAlignment(const Expr *E,
LValueBaseInfo *BaseInfo,
if (CE->getCastKind() == CK_AddressSpaceConversion)
Addr = CGF.Builder.CreateAddrSpaceCast(
Addr, CGF.ConvertType(E->getType()), ElemTy);
+
@@ -4309,16 +4292,39 @@ static Value *emitPointerArithmetic(CodeGenFunction
&CGF,
// future proof.
llvm::Type *elemTy;
if (elementType->isVoidType() || elementType->isFunctionType())
-elemTy = CGF.Int8Ty;
+elemTy = Int8Ty;
else
-elemTy = CGF.ConvertTypeFor
https://github.com/efriedma-quic approved this pull request.
LGTM, assuming there aren't any non-trivial changes to the regression tests.
(I looked at the code changes, but I skimmed the test changes.)
https://github.com/llvm/llvm-project/pull/150248
___
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/152411
The clang side of the calling convention code for arm64 vs. arm64ec is close
enough that this isn't really noticeable in most cases, but the rule for
choosing whether to pass a struct directly or indirect
efriedma-quic wrote:
Ping
https://github.com/llvm/llvm-project/pull/151053
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/152076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/152076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
I think I'd prefer to split the pointer authentication changes into a separate
patch; I'm not sure I'm comfortable reviewing that bit.
Other changes look fine.
https://github.com/llvm/llvm-project/pull/152076
_
@@ -2294,6 +2294,18 @@ llvm::Value *CodeGenFunction::EmitDynamicCast(Address
ThisAddr,
DestRecordTy->getAsCXXRecordDecl()->isEffectivelyFinal() &&
CGM.getCXXABI().shouldEmitExactDynamicCast(DestRecordTy);
+ std::optional ExactCastInfo;
+ if
@@ -1722,41 +1728,95 @@ llvm::Value *ItaniumCXXABI::emitExactDynamicCast(
if (!Offset)
Offset = PathOffset;
else if (Offset != PathOffset) {
- // Base appears in at least two different places. Find the most-derived
- // object and see if it's a DestDecl.
efriedma-quic wrote:
> > We don't currently have a definition of what it means to "use" a value in a
> > way that would cause undefined behavior with poison.
>
> Which means stating it produces undefined behavior less accurate?
We have to document semantics that describe the behavior with all
https://github.com/efriedma-quic commented:
LGTM, thanks
https://github.com/llvm/llvm-project/pull/152066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -624,8 +624,15 @@ namespace {
CallArgList Args;
Args.add(RValue::get(Arg),
CGF.getContext().getPointerType(Var.getType()));
- auto Callee = CGCallee::forDirect(CleanupFn);
- CGF.EmitCall(FnInfo, Callee, ReturnValueSlot(), Args);
+ bo
1 - 100 of 1803 matches
Mail list logo
