@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are
defined:
value should be sign-extended to the extent required by the target's
ABI (which is usually 32-bits) by the caller (for a parameter) or
the callee (for a return value).
+``noext``
efriedma-quic wrote:
Can you give a self-contained example that shows why this is a problem? (I
mean, I can imagine there could be some interaction that causes issues, but I'm
not sure what that interaction is, in this context.)
https://github.com/llvm/llvm-project/pull/100785
@@ -2,7 +2,7 @@
; PR933
efriedma-quic wrote:
There shouldn't be tests in test/CodeGen/X86 using the default target triple...
probably the tests should be relocated or fixed.
https://github.com/llvm/llvm-project/pull/100757
@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are
defined:
value should be sign-extended to the extent required by the target's
ABI (which is usually 32-bits) by the caller (for a parameter) or
the callee (for a return value).
+``noext``
efriedma-quic wrote:
I agree you want to look through some casts... but I'd like to see a check of
`getCastKind()` to ensure the cast you're looking through is a cast you're
expecting to see. Skipping over CK_BitCast should be fine; I'm concerned
you'll end up skipping over something that
@@ -0,0 +1,99 @@
+// RUN: %clang_cc1 -emit-llvm %s -triple x86_64-unknown-linux-gnu -o - |
FileCheck %s
efriedma-quic wrote:
Please don't merge an "auto-generated" file that isn't actually autogenerated
by the in-tree version.
(Is --check-attributes not what
@@ -0,0 +1,99 @@
+// RUN: %clang_cc1 -emit-llvm %s -triple x86_64-unknown-linux-gnu -o - |
FileCheck %s
efriedma-quic wrote:
Consider using update_cc_test_checks.py.
I'd like to see checks that we emit convergence tokens on targets where that's
the default.
https://github.com/efriedma-quic commented:
As a matter of ensuring the behavior is predictable, I don't like
IgnoreParenImpCasts(), and more generally looking through casts without
checking the CastKind; it very easily leads to bugs because some casts have
important semantics. Particularly
https://github.com/efriedma-quic approved this pull request.
LGTM
(Please cherry-pick to 19; I'd like to have this in 19. And maybe
https://github.com/cjacek/llvm-project/commit/4febef20ab27ef4440e9dccf3cc65dd6be1f4d7c,
if you wouldn't mind opening a pull request for that.)
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/96906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -532,9 +533,298 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
@@ -2799,9 +2799,30 @@ CodeGenFunction::EmitLoadOfReference(LValue RefLVal,
llvm::LoadInst *Load =
Builder.CreateLoad(RefLVal.getAddress(), RefLVal.isVolatile());
CGM.DecorateInstructionWithTBAA(Load, RefLVal.getTBAAInfo());
- return
@@ -1,8 +1,8 @@
// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple -o - %s -O2 |
FileCheck %s
-// Make sure the call to b() doesn't get optimized out.
+// Make sure the call to b() is eliminated.
extern struct x {char& x,y;}y;
int b();
int a() { if (!) b(); }
efriedma-quic wrote:
Missing testcase for the generated IR.
https://github.com/llvm/llvm-project/pull/100637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
/cherry-pick 20eff68
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic milestoned
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
There's some existing coverage of the affected diagnostics, which shows we
continue to produce those diagnostics... but I added a few more tests for
in-class static member variables.
https://github.com/llvm/llvm-project/pull/99579
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/99579
>From 1137011c51285b083cab6c15de670e64337d3de0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 18 Jul 2024 14:51:13 -0700
Subject: [PATCH 1/6] [ExprConstant] Handle shift overflow the same way as
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/99579
>From 1137011c51285b083cab6c15de670e64337d3de0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 18 Jul 2024 14:51:13 -0700
Subject: [PATCH 1/6] [ExprConstant] Handle shift overflow the same way as
@@ -0,0 +1,7 @@
+// RUN: not %clang_cc1 -S %s -o /dev/null 2>&1 | FileCheck %s
efriedma-quic wrote:
Please use "-verify" to check clang diagnostics, not FileCheck.
Is there any existing file with inline asm diagnostics this can be added to?
@@ -2751,7 +2751,10 @@ void CodeGenFunction::EmitAsmStmt(const AsmStmt ) {
if (RequiresCast) {
unsigned Size = getContext().getTypeSize(QTy);
-Ty = llvm::IntegerType::get(getLLVMContext(), Size);
+if (Size)
+ Ty =
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/100040
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10909,6 +10909,14 @@ QualType Sema::CheckAdditionOperands(ExprResult ,
ExprResult ,
if (isObjCPointer && checkArithmeticOnObjCPointer(*this, Loc, PExp))
return QualType();
+ // Arithmetic on label addresses is normally allowed, except when we add
+ // a ptrauth
efriedma-quic wrote:
Empty fields sometimes don't have a corresponding LLVM field number, in order
to make the layout work correctly. We slightly extended the cases where this
applies recently; see #96422.
https://github.com/llvm/llvm-project/pull/99574
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/99579
___
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/99579
>From 1137011c51285b083cab6c15de670e64337d3de0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 18 Jul 2024 14:51:13 -0700
Subject: [PATCH 1/5] [ExprConstant] Handle shift overflow the same way as
efriedma-quic wrote:
Added a few more tests; let me know if there are other tests I should be
considering.
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/99579
>From 1137011c51285b083cab6c15de670e64337d3de0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 18 Jul 2024 14:51:13 -0700
Subject: [PATCH 1/4] [ExprConstant] Handle shift overflow the same way as
efriedma-quic wrote:
Filed #99680 and #99684 for issues caused by custom codepaths for evaluating
ICEs. Hopefully we can improve that at some point.
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
@@ -142,7 +142,7 @@ constexpr int arb(int n) { // expected-note {{declared
here}}
expected-note {{function parameter 'n' with unknown value
cannot be used in a constant expression}}
}
constexpr long Overflow[(1 << 30) << 2]{}; // expected-warning {{requires 34
efriedma-quic wrote:
Pushed new version with an update to make Sema::VerifyIntegerConstantExpression
slightly more strict. That handles the cases where the errors were getting
dropped. The tradeoff is that we're more strict about arithmetic overflow in
certain integer constant expressions
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/99579
>From 1137011c51285b083cab6c15de670e64337d3de0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 18 Jul 2024 14:51:13 -0700
Subject: [PATCH 1/3] [ExprConstant] Handle shift overflow the same way as
@@ -2849,19 +2849,23 @@ static bool handleIntIntBinOp(EvalInfo , const
BinaryOperator *E,
if (SA != RHS) {
Info.CCEDiag(E, diag::note_constexpr_large_shift)
<< RHS << E->getType() << LHS.getBitWidth();
+ if (!Info.noteUndefinedBehavior())
+
@@ -142,7 +142,7 @@ constexpr int arb(int n) { // expected-note {{declared
here}}
expected-note {{function parameter 'n' with unknown value
cannot be used in a constant expression}}
}
constexpr long Overflow[(1 << 30) << 2]{}; // expected-warning {{requires 34
@@ -200,14 +200,7 @@ namespace LongInt {
};
enum shiftof {
-X = (1<<-29), // all-error {{expression is not an integral constant
expression}} \
- // all-note {{negative shift count -29}}
-
-X2 = (-1<<29), // cxx17-error {{expression is not an integral
efriedma-quic wrote:
This seems fine.
https://github.com/llvm/llvm-project/pull/99267
___
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/99574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Posted #99579.
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/99579
We have a mechanism to allow folding expressions that aren't ICEs as an
extension; use it more consistently.
This ends up causing bad effects on diagnostics in a few cases, but that's not
specific to
efriedma-quic wrote:
I think the issue is the usage of "Info.EvalStatus.Diag" to determine whether
we consider the expression an ICE; that's going to lead to unpredictable
results, and it's not how we handle things anywhere else. Not sure what the
goal of that change is.
Separately,
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -688,7 +688,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/96025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -6886,6 +6886,13 @@ static void checkAttributesAfterMerging(Sema ,
NamedDecl ) {
}
}
+ if (HybridPatchableAttr *Attr = ND.getAttr()) {
+if (!ND.isExternallyVisible()) {
+ S.Diag(Attr->getLocation(),
+
efriedma-quic wrote:
Oh, I see, there are two checks: one for the "align" attribute, and a separate
check for the natural alignment of the type.
I'm trying out changing the limit to see how hard it actually is.
https://github.com/llvm/llvm-project/pull/98629
@@ -465,7 +465,12 @@ class ResultObjectVisitor : public
AnalysisASTVisitor {
}
if (auto *DIE = dyn_cast(E)) {
- PropagateResultObject(DIE->getExpr(), Loc);
+ // If it has a rewritten init, we should propagate to that. If it
doesn't,
+ // then the
efriedma-quic wrote:
> I was under the impression those bits were still needed for Chromium. CC
> @dschuff
Oh, clang/lib/CodeGen/Targets/PNaCl.cpp is still live for mipsel-nacl target
triple. Which we also have zero tests for, but I guess that's a separate issue.
https://github.com/efriedma-quic approved this pull request.
LGTM
Please don't use `[test]` as a prefix in commit messages; just use the same
prefix you'd use for the code change, e.g. `[clang codegen]`
https://github.com/llvm/llvm-project/pull/98704
https://github.com/efriedma-quic commented:
What's the relationship between the max vector alignment, and choosing whether
to return a vector directly? As long as clang isn't emitting the byval
attribute, I don't think it's the frontend's problem.
https://github.com/efriedma-quic commented:
Bitfield load and store operations should be done using the same offset/size we
normally use to access the bitfield; unconditionally using byte load/store
operations will impair optimizations/performance. I guess this might not be
possible when
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/75371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2538,6 +2541,311 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+namespace {
+
+struct PaddingClearer {
+ PaddingClearer(CodeGenFunction )
+ : CGF(F),
@@ -2538,6 +2541,311 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+namespace {
+
+struct PaddingClearer {
+ PaddingClearer(CodeGenFunction )
+ : CGF(F),
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/98949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
There is no such thing as "generic" LLVM IR, in general: so many
target-specific aspects of C have to be directly encoded into the IR, so
there's no way to actually make it generic. In this respect, the "le32/le64"
targets aren't really any more generic than any other
efriedma-quic wrote:
It looks like the removal missed a few bits: PNaClABIBuiltinVaList and
clang/lib/CodeGen/Targets/PNaCl.cpp weren't removed.
> Unfortunately, this utterly breaks Halide, which was in fact relying on both
> of these targets.
We can temporarily revert this, but we aren't
efriedma-quic wrote:
> BTW, I think the limitation I'm hitting is introduced by
> https://reviews.llvm.org/D121898 .
The limitation existed before that; we just miscompiled instead of reporting an
error.
https://github.com/llvm/llvm-project/pull/98629
efriedma-quic wrote:
There are two ways we could analyze, this, I think:
- EmitVAArg is doing something which disagrees with the classification done by
classifyArgumentType, so that's a bug in EmitVAArg.
- classifyArgumentType is returning a malformed value; EmitVAArg should assert
that it
https://github.com/efriedma-quic approved this pull request.
Not what I was expecting, but this works, sure. LGTM.
https://github.com/llvm/llvm-project/pull/98832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -6106,11 +6111,14 @@ void CodeGenModule::emitIFuncDefinition(GlobalDecl GD) {
Aliases.push_back(GD);
- llvm::Type *DeclTy = getTypes().ConvertTypeForMem(D->getType());
- llvm::Type *ResolverTy = llvm::GlobalIFunc::getResolverFunctionType(DeclTy);
+ // The resolver
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/98832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
efriedma-quic wrote:
It's used in the same ASTContext code that's modified by this patch. Probably
fine to adjust it
efriedma-quic wrote:
The size of ArgFlagsTy is, as far as I can tell, basically irrelevant: it's
only used as part of computing the calling convention in isel. I don't think
anyone will notice if it's a few bytes larger.
The non-byval alignment limit was last adjusted in
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,43 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// The test may fail as time out on windows
+// REQUIRES: system-linux
+
+// RUN: %clang -S -O3 -emit-llvm -o - -x c++ %s | FileCheck %s
https://github.com/efriedma-quic commented:
>> How does this interact with StrictFP?
> I don't think it related to StrictFP, because we only care whether the global
> variable errno is modified? which may bring in alias to other global
> variable. As now the type of errno is int, so we record
efriedma-quic wrote:
Does this affect the generated IR in some existing case? If it does, can you
include a regression test in clang/test/CodeGen?
https://github.com/llvm/llvm-project/pull/98668
___
cfe-commits mailing list
efriedma-quic wrote:
(The relevant bitfield is was renamed to MemAlign, and is now in
llvm/include/llvm/CodeGen/TargetCallingConv.h)
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
> max aligment [...] LLVM Verifier accepts is 2^14
The verifier limit in most places is 2^32. It looks like 2^14 is specifically
for ByVal. And there isn't really any good reason for that limit; it was
arbitrarily chosen in b567e3ffb0, nearly two decades ago, and could
https://github.com/efriedma-quic approved this pull request.
https://github.com/llvm/llvm-project/pull/96422
___
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/98525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -310,6 +310,41 @@ bool CodeGen::isEmptyRecord(ASTContext , QualType
T, bool AllowArrays,
return true;
}
+bool CodeGen::isEmptyFieldForLayout(const ASTContext ,
+const FieldDecl *FD) {
+ if (FD->isZeroLengthBitField(Context))
+
@@ -152,7 +152,7 @@ class ARMTargetCodeGenInfo : public TargetCodeGenInfo {
diag::warn_target_unsupported_branch_protection_attribute)
<< Arch;
} else {
- BPI.setFnAttributes(*Fn);
+ setBranchProtectionFnAttributes(BPI,
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/98451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/98451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,7 +1,19 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-linux-gnu -o - | FileCheck %s
--check-prefixes=CHECK,EMPTY
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-windows-msvc -o - | FileCheck
%s
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96422
___
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/96422
___
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.
The updated approach makes sense, I think.
Please check that AArch64TargetLowering::LowerRETURNADDR works correctly when
LR is reserved; I think it should just work, but I'm not completely sure.
Otherwise LGTM
efriedma-quic wrote:
The usual mechanism for emitting deferred definitions involves
CodeGenModule::EmitDeferred(): declarations get added to the list by
addDeferredDeclToEmit(), then it goes through to emit all the declarations on
the list. So it's a matter of making sure the resolver ends
@@ -185,6 +203,18 @@ CALL_AO(PackedMembers)
// CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1
{{.*}}i64 16, i1 {{.*}})
// CHECK: ret ptr
+// WithEmptyField copy-assignment:
+// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}}
@@ -1,7 +1,17 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
// PR4390
struct sysfs_dirent {
- union { struct sysfs_elem_dir {} s_dir; };
+ union { struct sysfs_elem_dir { int x; } s_dir; };
@@ -137,6 +137,16 @@ bool isEmptyField(ASTContext , const FieldDecl
*FD, bool AllowArrays,
bool isEmptyRecord(ASTContext , QualType T, bool AllowArrays,
bool AsIfNoUniqueAddr = false);
+/// isEmptyFieldForLayout - Return true iff the field is "empty", that
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
efriedma-quic wrote:
The question is, if LTO merges two bitcode modules together with different
settings for the flag, how do you want the backend to behave? Usually you want
it to just continue to apply to the same functions it would have without LTO;
the only way to represent that is a
@@ -4917,6 +4917,9 @@ foreach i = {1-31} in
def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
HelpText<"Reserve the x"#i#" register (AArch64/RISC-V only)">;
+def mlr_for_calls_only : Flag<["-"], "mlr-for-calls-only">,
Group,
efriedma-quic wrote:
Name
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
efriedma-quic wrote:
The issue is just that clang expects the following to compile. And with the
current version of the patch, I think we end up crashing in the backend.
```
@f.x = internal global i32 trunc (i64 sub (i64 ptrtoint (ptr blockaddress(@f,
%A) to i64), i64 ptrtoint (ptr
efriedma-quic wrote:
Under the proposed ABI, `&&` is actually "sign(A)-sign(B)". Which is a
constant, but not one which can be represented as a relocation (as far as I
know).
https://github.com/llvm/llvm-project/pull/97647
___
cfe-commits mailing
efriedma-quic wrote:
It looks like in the latest patch, there's still a couple uses of isZeroSize()
in CGExprConstant?
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
> > For CGClass, it's not directly tied to the LLVM structure layout, but I'm
> > not sure the generated code would be semantically correct if an "empty"
> > field that isn't isEmpty() overlaps with actual data.
>
> I haven't addressed this yet. To clarify, are you
efriedma-quic wrote:
Why do we want a module flag, and not a function attribute? Module flags are
generally problematic during LTO, so we try to avoid them if they aren't truly
necessary.
https://github.com/llvm/llvm-project/pull/97524
___
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
We have a mechanism which specifically encodes the distinction we want here:
ReserveXRegisterForRA. This was implemented for debugging/regression tests
(see https://reviews.llvm.org/D132717), but we can expose it more generally.
Naming is hard, but maybe
efriedma-quic wrote:
I'm not against having a security hardening feature to avoid using LR as a GPR.
But we'd want to name it something different, to make it clear that it's a
security-hardening feature, not a guarantee that the compiler won't clobber LR.
1 - 100 of 1033 matches
Mail list logo
