https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Is there some reason this is an attribute, and not a calling convention, at the
IR level?
https://github.com/llvm/llvm-project/pull/101228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/101434
___
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/101434
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1136,15 +1135,15 @@ llvm::Value *CodeGenFunction::EmitCountedByFieldExpr(
return nullptr;
}
- llvm::Value *Zero = Builder.getInt32(0);
RecIndicesTy Indices;
-
getGEPIndicesToField(*this, RD, CountDecl, Indices);
+ if (Indices.empty())
+return nullptr;
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/101447
___
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/86388
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
A revert isn't necessary just for the missing release note; a followup PR is
fine.
https://github.com/llvm/llvm-project/pull/100637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -119,8 +119,6 @@ static Cl::Kinds ClassifyInternal(ASTContext , const
Expr *E) {
// First come the expressions that are always lvalues, unconditionally.
case Expr::ObjCIsaExprClass:
-// C++ [expr.prim.general]p1: A string literal is an lvalue.
- case
@@ -150,6 +148,12 @@ static Cl::Kinds ClassifyInternal(ASTContext , const
Expr *E) {
case Expr::OMPIteratorExprClass:
return Cl::CL_LValue;
+// C++ [expr.prim.general]p1: A string literal is an lvalue.
+// Except we special case them as prvalues when they are
@@ -119,8 +119,6 @@ static Cl::Kinds ClassifyInternal(ASTContext , const
Expr *E) {
// First come the expressions that are always lvalues, unconditionally.
case Expr::ObjCIsaExprClass:
-// C++ [expr.prim.general]p1: A string literal is an lvalue.
- case
efriedma-quic wrote:
Right, asinf doesn't exist on Windows (see
llvm/lib/Analysis/TargetLibraryInfo.cpp). We probably need code to promote
calls to llvm.asin.f32 to 64-bit. Not sure how hard it would be to revert
this... probably easier to fix forward if we can do that quickly.
We'll need
efriedma-quic wrote:
Is there some way we can avoid the additional domtree construction?
Particularly in cases where the pass doesn't do anything.
https://github.com/llvm/llvm-project/pull/101114
___
cfe-commits mailing list
@@ -4057,6 +4057,10 @@ bool Sema::MergeFunctionDecl(FunctionDecl *New,
NamedDecl *, Scope *S,
NewQType))
return MergeCompatibleFunctionDecls(New, Old, S, MergeTypeWithOld);
+if (getLangOpts().HLSL &&
efriedma-quic wrote:
Don't have time to continue looking at this for now.
https://github.com/llvm/llvm-project/pull/94282
___
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/94282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4057,6 +4057,10 @@ bool Sema::MergeFunctionDecl(FunctionDecl *New,
NamedDecl *, Scope *S,
NewQType))
return MergeCompatibleFunctionDecls(New, Old, S, MergeTypeWithOld);
+if (getLangOpts().HLSL &&
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/101083
___
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:
Approach generally seems fine; not sure I'll have time to look more closely.
https://github.com/llvm/llvm-project/pull/101083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/99849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> > And C++17 rules forbid a copy on the caller side: "guaranteed copy elision"
> > means semantically, there is no copy.
>
> An extra copy is permitted for trivially-copyable types; otherwise we'd be
> required to pass and return all classes indirectly. So we're not
efriedma-quic wrote:
>So I think this supports the notion that this should be a dialect, and we have
>to wire defaults differently in MSVC mode as well.
I doubt anyone is intentionally depending on equality here.
> C++ does have some restrictions on accessing objects that are being
>
efriedma-quic wrote:
We already have some code for detecting variable inits that access the
variable; see isAccessedBy() in CGDecl.cpp.
https://github.com/llvm/llvm-project/pull/101038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -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 - 100 of 1056 matches
Mail list logo
