https://github.com/rjmccall approved this pull request.
Sure, LGTM.
https://github.com/llvm/llvm-project/pull/93956
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1328,15 +1328,15 @@ void AggExprEmitter::VisitChooseExpr(const ChooseExpr
*CE) {
void AggExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
Address ArgValue = Address::invalid();
- Address ArgPtr = CGF.EmitVAArg(VE, ArgValue);
+ RValue ArgPtr = CGF.EmitVAArg(VE, ArgValue);
rjmccall wrote:
> > I was hoping that you might push this down into the target code — if you
> > make emitVoidPtrVAArg return an RValue, that'll handle about half of the
> > targets. Most of the rest will just need an EmitLoadOfLValue at the end
>
> Ok, that seems doable, but I'm having
https://github.com/rjmccall commented:
I was hoping that you might push this down into the target code — if you make
`emitVoidPtrVAArg` return an `RValue`, that'll handle about half of the
targets. Most of the rest will just need an `EmitLoadOfLValue` at the end.
MIPS (which is the target
@@ -5988,12 +5988,29 @@ CGCallee
CGCallee::prepareConcreteCallee(CodeGenFunction ) const {
/* VarArg handling */
-Address CodeGenFunction::EmitVAArg(VAArgExpr *VE, Address ) {
- VAListAddr = VE->isMicrosoftABI()
- ? EmitMSVAListRef(VE->getSubExpr())
-
@@ -1328,15 +1328,15 @@ void AggExprEmitter::VisitChooseExpr(const ChooseExpr
*CE) {
void AggExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
Address ArgValue = Address::invalid();
- Address ArgPtr = CGF.EmitVAArg(VE, ArgValue);
+ RValue ArgPtr = CGF.EmitVAArg(VE, ArgValue);
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T,
bool ForBitField) {
return R;
}
+bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy,
+llvm::Type *LLVMTy) {
+ CharUnits ASTSize =
@@ -64,6 +65,20 @@ static llvm::cl::opt ClSanitizeGuardChecks(
"ubsan-guard-checks", llvm::cl::Optional,
llvm::cl::desc("Guard UBSAN checks with `llvm.allow.ubsan.check()`."));
+//======//
+//
rjmccall wrote:
I agree with Eli. We should trust external record layout to the extent that it
generates a valid layout, but if it generates something with overlapping
fields, or that runs outside the claimed bounds of the type, we'll just end up
crashing in IRGen. I assume those things are
@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
return llvm::UndefValue::get(ArgTy);
}
- // FIXME Volatility.
- llvm::Value *Val = Builder.CreateLoad(ArgPtr);
-
- // If EmitVAArg promoted the type, we must truncate it.
- if (ArgTy !=
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address
Addr, bool Volatile,
}
llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) {
- // Bool has a different representation in memory than in registers.
- if
@@ -1533,9 +1533,17 @@ void CodeGenFunction::EmitReturnStmt(const ReturnStmt
) {
Builder.CreateStore(Result.getScalarVal(), ReturnValue);
} else {
switch (getEvaluationKind(RV->getType())) {
-case TEK_Scalar:
- Builder.CreateStore(EmitScalarExpr(RV),
@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
return llvm::UndefValue::get(ArgTy);
}
- // FIXME Volatility.
- llvm::Value *Val = Builder.CreateLoad(ArgPtr);
-
- // If EmitVAArg promoted the type, we must truncate it.
- if (ArgTy !=
@@ -1774,6 +1784,22 @@ llvm::Constant
*ConstantEmitter::emitForMemory(CodeGenModule ,
return Res;
}
+ if (destType->isBitIntType()) {
+if (!CGM.getTypes().LLVMTypeLayoutMatchesAST(destType, C->getType())) {
+ // Long _BitInt has array of bytes as in-memory
@@ -2044,6 +2048,12 @@ llvm::Value *CodeGenFunction::EmitFromMemory(llvm::Value
*Value, QualType Ty) {
return emitBoolVecConversion(V, ValNumElems, "extractvec");
}
+ if (hasBooleanRepresentation(Ty) || Ty->isBitIntType()) {
+llvm::Type *ResTy = ConvertType(Ty);
+
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address
Addr, bool Volatile,
}
llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) {
rjmccall wrote:
```suggestion
/// Converts a scalar value from its primary IR
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address
Addr, bool Volatile,
}
llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) {
- // Bool has a different representation in memory than in registers.
- if
rjmccall wrote:
Changing a type trait is generally always an ABI problem, but yeah, if this
hasn't been released yet, we're still free to fix basic bugs.
https://github.com/llvm/llvm-project/pull/92103
___
cfe-commits mailing list
https://github.com/rjmccall approved this pull request.
This LGTM. Please reach out to the Fuchsia and XL folks if you can, but we
don't need to hold up the PR over it.
https://github.com/llvm/llvm-project/pull/90462
___
cfe-commits mailing list
@@ -2415,46 +2415,112 @@ DiagnosticBuilder
ItaniumRecordLayoutBuilder::Diag(SourceLocation Loc,
return Context.getDiagnostics().Report(Loc, DiagID);
}
+/// https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD
+/// POD for the purpose of layout
+/// In general, a type
@@ -2415,46 +2415,112 @@ DiagnosticBuilder
ItaniumRecordLayoutBuilder::Diag(SourceLocation Loc,
return Context.getDiagnostics().Report(Loc, DiagID);
}
+/// https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD
+/// POD for the purpose of layout
+/// In general, a type
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/85886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
I think you're right about the intended logic being to check for a definition,
especially given the wording of the warning. IIRC, we didn't have some of
these high-level checks at the time.
With that said, I think you need to check if a definition
rjmccall wrote:
My experience is that compiler writers are really good at hacking in special
cases to make their test cases work and really bad at recognizing that their
case isn't as special as they think. There are three types already called out
for special treatment in
rjmccall wrote:
If you want to do things that way, you will need to (1) generalize CodeGenTypes
with a new API that will return this load/store type when applicable and (2)
look at all the places we call `ConvertTypeForMem`, `EmitToMemory`, and
`EmitFromMemory` to make sure they do the right
rjmccall wrote:
Hmm. I think this is actually pretty different from the `bool` pattern.
Suppose we're talking about `_BitInt(N)`. Let `BYTES := ceil(N/8)`, and let
`BITS := BYTES * 8`.
The problem being presented here is this:
1. For at least some values of `N`, we cannot use LLVM's `iN`
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90329
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
The Apple fork does actually use this downstream (for address-sensitive
`__ptrauth`), and we've recently (finally) been making progress in upstreaming
that work. Obviously, we could delete it and then reinstate it when we catch
up to this point in
@@ -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
@@ -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
@@ -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
@@ -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
rjmccall wrote:
Great, thanks! @Midar, if you can fix this code up so that these strings are
created in one place (and test the new output, since this is not NFC), I'd be
happy to sign off.
https://github.com/llvm/llvm-project/pull/88713
___
https://github.com/rjmccall approved this pull request.
This seems fine. Is there any existing bookkeeping we no longer need to do if
we're going to have this RAII object in scope during function parsing?
https://github.com/llvm/llvm-project/pull/85605
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/88713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
At first, I was worried that this was an ABI break. Then I noticed the
internal inconsistency within this single file, and so I became worried that it
was an ABI *fix*. But then I noticed that the normal selector-emission code
actually makes these
rjmccall wrote:
> Ah, okay, thank you! I had two concerns, but I think neither are valid now
> that I better understand how `ExtQuals` works: 1) I thought we were
> increasing the in-memory size of `Qualifiers` in a way that matter (like
> `SplitQualType`, `ExtProtoInfo` primarily),
AFAIK,
rjmccall wrote:
> > @AaronBallman See test results from compile-time-tracker here:
> > https://llvm-compile-time-tracker.com/compare.php?from=693a458287d019c5c6a66fe3019d099df2978cdb=dbb5e29d136a18060ba6759b328ad80fa9cea649.
> > It looks like that there is a statistically meaningful difference,
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
It's my patch, so me signing off isn't very meaningful.
https://github.com/llvm/llvm-project/pull/84384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy =
rjmccall wrote:
> Libcall emission needs to know what AS to use for pointer arguments to things
> like __sync/__atomic implementations and various string-y mem*/str*
> functions. That's the main one that comes to mind from our experience in
> CHERI LLVM, and current LLVM just assumes that's
rjmccall wrote:
> I'm not quite sure how to parse this comment, could you explain what you have
> in mind here? The problem is precisely that the FE assumes 0 is fine / picks
> it by default, which ends up into dangerzones when e.g. a target happened to
> use 0 to point to private (stack). I
rjmccall wrote:
> Why can't we just declare that the "generic" address-space must always be 0?
> The specific numbers we use for address-spaces are completely arbitrary
> anyway.
I don't think this works; there's nothing that LLVM could possibly do with a
generic AS that would justify it
rjmccall wrote:
It's very uncommon for LLVM to need to come up with an address space on its
own, as opposed to just propagating the original address space of some memory /
operation as chosen by the frontend. LLVM occasionally creates new storage
allocations, but usually they're
rjmccall wrote:
It'll be tested in a follow-up commit which actually adds parsing and Sema
support for these as qualifiers. That should be sufficient rather than adding
a whole unit-test apparatus. Daniil is just trying to avoid landing this in a
single massive commit.
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
Doing in in one commit this time seems fine.
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rjmccall wrote:
Hmm. The best solution there is probably to use a consistent representation
but introduce some sort of `GLValueThatTheStandardAbsurdlyPretendsIsAnRValue`
(definitely the only and best word for this, ship it) that we can use as the
value category. IIRC, something similar
rjmccall wrote:
Hmm. Well, you'd have to ask @zygoloid what he was thinking in
r183721/r183859, but I don't think it's correct in general to be looking at E
(the MTE sub-expression) for most of the logic here. IIRC, the MTE
sub-expression is essentially the initializer for the materialized
rjmccall wrote:
Well, sometimes we do leave FIXMEs that end up being suprisingly easy to fix.
But what FIXME are we talking about here? The patch doesn't remove any FIXMEs,
or for that matter include any tests.
https://github.com/llvm/llvm-project/pull/85541
@@ -0,0 +1,74 @@
+//===- SemaOpenACC.h - Semantic Analysis for OpenACC constructs
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
https://github.com/rjmccall approved this pull request.
Okay. Thanks for putting up with such a protracted review! I really like
where we've ended up.
LGTM. Please wait a few days before merging to give other reviewers a chance
to give final feedback.
rjmccall wrote:
Yeah, I don't think we need this change. The comment is a little unnecessary,
but it's not a big deal. Really, the code ought to be using a visitor instead
of a `switch`.
https://github.com/llvm/llvm-project/pull/85921
___
https://github.com/rjmccall closed
https://github.com/llvm/llvm-project/pull/86011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall created
https://github.com/llvm/llvm-project/pull/86011
The old logic expects the call to be the last thing we emitted, and since it
kicks in before we emit cleanups, and since `swiftasynccall` functions always
return void, that's likely to be true. "Likely" isn't
@@ -1495,6 +1495,10 @@ Decl *Parser::ParseFunctionDefinition(ParsingDeclarator
,
return Actions.ActOnFinishFunctionBody(Res, nullptr, false);
}
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
+ Sema::FPFeaturesStateRAII
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall commented:
This looks great, thanks! I have a few editorial nits, and there's an
assertion that seems off, but otherwise this looks ready to go.
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall approved this pull request.
https://github.com/llvm/llvm-project/pull/85623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2508,6 +2508,10 @@ Decl *Parser::ParseFunctionStatementBody(Decl *Decl,
ParseScope ) {
Sema::PragmaStackSentinelRAII
PragmaStackSentinel(Actions, "InternalPragmaState", IsCXXMethod);
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
+
https://github.com/rjmccall commented:
Alright. I don't really have a problem with doing this, and this seems like
basically the right approach. You're applying the attributes in the wrong
place, though.
https://github.com/llvm/llvm-project/pull/85605
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3552,6 +3552,15 @@ class CastExpr : public Expr {
/// function that it invokes.
NamedDecl *getConversionFunction() const;
+ /// Path through the class hierarchy taken by a `DerivedToBase` or
+ /// `UncheckedDerivedToBase` cast. For each derived-to-base edge in the
rjmccall wrote:
> > Hmm. Is there some sort of optimization in IRGen that we need to suppress
> > here, or is it something in LLVM code gen? Presumably normal LLVM
> > optimization passes all just skip `optnone` functions.
>
> The issue #62098 demonstrates such case.
Okay. So if I
https://github.com/rjmccall approved this pull request.
Yeah, it's fine with me.
https://github.com/llvm/llvm-project/pull/85347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
Yeah, we don't need to care about the actual bit offset of the zero-width
bit-field as long as we honor the non-interference properties across it. I'll
take a look at the patch, thanks.
https://github.com/llvm/llvm-project/pull/65742
rjmccall wrote:
Hmm. Is there some sort of optimization in IRGen that we need to suppress
here, or is it something in LLVM code gen? Presumably normal LLVM optimization
passes all just skip `optnone` functions.
Mostly I'm wondering how far we're expected to go with `optnone`.
@@ -0,0 +1,265 @@
+Pointer Authentication
+==
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic
protection against exploiting a broad class of memory bugs to take control of
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
https://github.com/rjmccall commented:
Thank you, the structure looks great! Mostly style and clarity comments from
here.
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rjmccall wrote:
> @rjmccall Re asking GCC developers about gcc_struct on non-x86:
> https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs
> aren't really worried about this or I can't properly write emails (what's
> totally possible).
Alright, well, we tried. I think
rjmccall wrote:
> I'm seeing evidence that this might be a chatty diagnostic in practice:
>
> https://sourcegraph.com/github.com/torvalds/linux@90d35da658da8cff0d4ecbb5113f5fac9d00eb72/-/blob/kernel/fork.c?L311
>
>
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -858,6 +861,10 @@ class TargetInfo : public TransferrableTargetInfo,
return PointerWidth;
}
+ /// Return true, iff unaligned accesses are a single instruction (rather than
rjmccall wrote:
```suggestion
/// Return true iff unaligned accesses are a
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
1 - 100 of 686 matches
Mail list logo
