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
cfe-commits@lists.llvm.org
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 a
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 goi
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 tar
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
@@ -2538,6 +2541,311 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+namespace {
+
+struct PaddingClearer {
+ PaddingClearer(CodeGenFunction &F)
+ : CGF(F), CharWidth(CGF.getContext().ge
@@ -2538,6 +2541,311 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+namespace {
+
+struct PaddingClearer {
+ PaddingClearer(CodeGenFunction &F)
+ : CGF(F), CharWidth(CGF.getContext().ge
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
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 unio
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/llvm/llvm-project/pull/986
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
___
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/llvm/llvm
@@ -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 CXXDe
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
___
@@ -6886,6 +6886,13 @@ static void checkAttributesAfterMerging(Sema &S,
NamedDecl &ND) {
}
}
+ if (HybridPatchableAttr *Attr = ND.getAttr()) {
+if (!ND.isExternallyVisible()) {
+ S.Diag(Attr->getLocation(),
+ diag::warn_attribute_hybrid_patchable_n
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -688,7 +688,34 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
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
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, Sema::Ad
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 shif
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 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:
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
@@ -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
@@ -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
@@ -2849,19 +2849,23 @@ static bool handleIntIntBinOp(EvalInfo &Info, const
BinaryOperator *E,
if (SA != RHS) {
Info.CCEDiag(E, diag::note_constexpr_large_shift)
<< RHS << E->getType() << LHS.getBitWidth();
+ if (!Info.noteUndefinedBehavior())
+r
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
ot
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 (c
@@ -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:
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
cfe-commits@lists.llvm.o
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
ot
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://lists.llvm.org/cgi-bin/mailman/l
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
ot
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
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
___
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
This really shouldn't work this way: we should go throu
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr()
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr()
efriedma-quic wrote:
If you have a select with both wrapping and non-wrapping operands, is the
result wrapping? If you declare a variable as both wrapping and non-wrapping,
is it wrapping? If you declare a function parameter both wrapping and
non-wrapping, is it wrapping? If you assign to a
efriedma-quic wrote:
The C standard is small enough that if you comb through the C grammar
carefully, you can probably come up with explicitly rules for all the important
constructs, and verify they work. There's probably still a long tail of weird
interactions with current and future clang e
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the lamb
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
Zero/sign-extend attributes are also missing, I think.
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
To clarify, the code in llvm/ still needs to exist beca
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> > If you declare a variable as both wrapping and non-wrapping, is it wrapping?
>
> I am not sure how to do this. I am sure that with the magic of C anything is
> possible but I can't conceive a way to have a variable both have the
> attribute and not have the attribute (
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
Sign/zero-extend attributes led to real issues on some
efriedma-quic wrote:
> No. But I am confused, isn't this just shadowing a global variable with a
> lesser-scoped one. Are they the same? What behavior do we want here?
This is declaring, then defining, a global variable; sorry if that wasn't clear.
Probably should be an error? It'll be confus
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/90106
This code was apparently added in de0fe07eef, but never used.
I think more of the related code might actually dead, but I haven't tried to
dig more deeply.
>From b9e5e50524a6ff91badfd5729846d5c948f1d4ce M
efriedma-quic wrote:
Oh, I was confused that we had this code that doesn't appear to be doing
anything. If you actually have a plan, then we can keep it for now, I guess.
It might make sense to try to clarify some of the address-space related APIs:
if the caller doesn't want placeholder-stuff
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/90106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Attributes mostly do modify the type. The few that don't, like "aligned" and
"may_alias", are a constant source of problems because they get accidentally
stripped off. (I don't have any personal experience with "noderef".)
https://github.com/llvm/llvm-project/pull/86618
efriedma-quic wrote:
The pull request needs to be against llvm:release/18.x, not llvm:main.
https://github.com/llvm/llvm-project/pull/90118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
efriedma-quic wrote:
We don't merge anything against the release branch until the buildbots pass.
For the buildbots to run, someone needs to manually create a pull request
against 18.x branch containing both the original patch and whatever changes are
necessary to make the buildbots pass.
ht
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/90151
In the context of determining whether a class counts as an "aggregate", a
constructor template counts as a user-provided constructor.
Fixes #86384
>From 9adeffc9ee780c84a525ce0535a84508105e05ae Mon Sep 17
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
efriedma-quic wrote:
The approach makes sense. I'll defer to someone who's more familiar with this
code for the full review.
https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/90151
>From 9adeffc9ee780c84a525ce0535a84508105e05ae Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 25 Apr 2024 17:06:40 -0700
Subject: [PATCH 1/2] [clang codegen] Fix MS ABI detection of user-provided
c
efriedma-quic wrote:
Added release note.
https://github.com/llvm/llvm-project/pull/90151
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -62,6 +62,13 @@ namespace llvm {
LibFunc TheLibFunc, AttributeList AttributeList,
FunctionType *Invalid, ArgsTy... Args) = delete;
+ // Handle -mregparm for the given function.
+ // FIXME: This should likely be implemented in
+ /
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
Suggested text on the clang change:
FIXME: We should u
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/90303
There's some code in AggExprEmitter::VisitCXXParenListOrInitListExpr to try to
do early cleanup for GEPs for fields that aren't accessed. But it's unlikely to
actually save significant compile-time, and it
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/87750
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
efriedma-quic wrote:
Are you intentionally skipping implementing changes to __builtin_tan()?
https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/90151
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3123,8 +3123,22 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction &CGF,
Address VAListAddr,
RegAddr = Tmp.withElementType(LTy);
} else if (neededInt) {
-RegAddr = Address(CGF.Builder.CreateGEP(CGF.Int8Ty, RegSaveArea,
gp_offset),
- LTy, C
@@ -535,20 +535,24 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
elementType.isTriviallyCopyableType(CGF.getContext())) {
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
-LangAS AS = ArrayQTy.getAddressSpa
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89707
___
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/90048
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -908,6 +908,74 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
@@ -3133,15 +3149,13 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction &CGF,
Address VAListAddr,
// Copy into a temporary if the type is more aligned than the
// register save area.
-if (TyAlign.getQuantity() > 8) {
- Address Tmp = CGF.CreateMemTemp(Ty);
+
@@ -3122,9 +3122,25 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction &CGF,
Address VAListAddr,
CGF.Builder.CreateStore(V, CGF.Builder.CreateStructGEP(Tmp, 1));
RegAddr = Tmp.withElementType(LTy);
- } else if (neededInt) {
-RegAddr = Address(CGF.Builder.CreateG
@@ -715,6 +772,11 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE,
bool AllowOverwrite) {
if (CXXRD->getNumBases())
return false;
+ // See comment in getPadding().
+ bool ZeroInitPadding = !CGM.getLangOpts().CPlusPlus;
efriedma-quic wrot
@@ -1745,13 +1748,48 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
// Default-initialize to null.
EmitNullInitializationToLValue(FieldLoc);
}
+if (ZeroInitPadding) {
+ CharUnits TotalSize =
+ Dest.getPreferredSize(CGF.getContext(), D
@@ -5819,3 +5819,24 @@ specify the starting offset to begin embedding from. The
resources is treated
as being empty if the specified offset is larger than the number of bytes in
the resource. The offset will be applied *before* any ``limit`` parameters are
applied.
+
+Union an
@@ -1745,13 +1748,48 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
// Default-initialize to null.
EmitNullInitializationToLValue(FieldLoc);
}
+if (ZeroInitPadding) {
+ CharUnits TotalSize =
+ Dest.getPreferredSize(CGF.getContext(), D
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const
VarDecl &D,
}
return GV;
}
+ if (!getLangOpts().CPlusPlus) {
+// In C, when an initializer is given, the Linux kernel relies on clang to
+// zero-initialize all members not explicitly
@@ -42,6 +42,66 @@ using namespace CodeGen;
namespace {
class ConstExprEmitter;
+llvm::Constant *getPadding(const CodeGenModule &CGM, CharUnits PadSize) {
+ if (!CGM.getLangOpts().CPlusPlus) {
+// In C23 (N3096) $6.7.10:
+// """
+// If any object is initialized wi
@@ -0,0 +1,219 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -std=gnu11 -verify
-emit-llvm %s -o - | FileCheck %s
efriedma-quic wrote:
update_cc_test_checks.py, maybe? Unless it doesn't generate clear checks for
some reason.
https://github.com/llvm/ll
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/102896
___
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:
What's the state of byval handling with the current version of the patch?
https://github.com/llvm/llvm-project/pull/102896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
@@ -4,6 +4,28 @@
; CHECK-NOT: vmov
efriedma-quic wrote:
Extra check lines
https://github.com/llvm/llvm-project/pull/102896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -3056,18 +3014,26 @@ bool
ARMTargetLowering::IsEligibleForTailCallOptimization(
// Exception-handling functions need a special set of instructions to
indicate
// a return to the hardware. Tail-calling another function would probably
// break this.
- if (CallerF.hasF
@@ -3056,18 +3014,26 @@ bool
ARMTargetLowering::IsEligibleForTailCallOptimization(
// Exception-handling functions need a special set of instructions to
indicate
// a return to the hardware. Tail-calling another function would probably
// break this.
- if (CallerF.hasF
@@ -5085,7 +5085,7 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
RawAddress SRetAlloca = RawAddress::invalid();
llvm::Value *UnusedReturnSizePtr = nullptr;
if (RetAI.isIndirect() || RetAI.isInAlloca() || RetAI.isCoerceAndExpand()) {
-if (IsVirtu
https://github.com/efriedma-quic commented:
It probably makes sense to add a helper like the following to CodeGenModule or
something like that:
```
bool shouldZeroInitPadding() {
// Comment explaining reasoning for this rule
return !CGM.getLangOpts().CPlusPlus;
}
```
So we don't have `//
@@ -0,0 +1,43 @@
+; RUN: llc -mtriple=arm-eabi %s -o - | FileCheck %s
+
+; The repro example from
https://github.com/llvm/llvm-project/issues/57069#issuecomment-1212754850
+; Function Attrs: mustprogress nofree noinline norecurse nosync nounwind
sspstrong willreturn memory(none)
@@ -0,0 +1,43 @@
+; RUN: llc -mtriple=arm-eabi %s -o - | FileCheck %s
efriedma-quic wrote:
Please generate checks with update_llc_test_checks.py
https://github.com/llvm/llvm-project/pull/102896
___
cfe-commits mailing
https://github.com/efriedma-quic commented:
If a function is declared without a prototype (pre-C23), it doesn't mean it has
a void argument list; it means the argument list is undeclared. So you can't
just assume the argument list is void; you have to compute the argument types
from the actua
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
efriedma-quic wrote:
On targets with SIMD vectors (basical
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
efriedma-quic wrote:
> that sounds essentially what the op
efriedma-quic wrote:
Under the proposed ABI, `&&A-&&B` 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 maili
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 blockaddre
801 - 900 of 2042 matches
Mail list logo
