efriedma-quic wrote:
I didn't actually look at this PR closely before I commented.
I think the specific checks clang is doing here have to be part of clang: in
particular, clang needs to translate from gcc syntax to LLVM IR asm syntax, and
that requires parsing the constraints. So these
efriedma-quic wrote:
Hmm... so basically, the program is partitioned into parts with branch
enforcement disabled, and parts with branch enforcement enabled, and there's
some defined transition between the two? So in this case, the metadata is
nonsense, and you want to ignore it. I guess
efriedma-quic wrote:
> and that implies (at least to me) that an expression cannot form an infinity
> to begin with, so the act of trying to expand INFINITY is nonsensical in that
> case, right?
It's undefined behavior at runtime.
I don't think we need to worry too much about what the C
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
I'm not sure about tying this to __FINITE_MATH_ONLY__; -ffinite-math-only
doesn't mean infinity doesn't exist, it just means you're promising that you
won't use floating-point arithmetic/comparison ops on infinity. Which is
weird, but that's
@@ -707,7 +707,39 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
I guess the clang calling convention code never uses MMX types for
passing/returning values?
Have you looked at the code quality? #41665 mentions potential issues with
widening vectors.
This doesn't touch inline asm or _mm_empty; I guess you're leaving that for a
efriedma-quic wrote:
(I'd like a re-review of the latest version: I made significant revisions to
address the tail-padding issues.)
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
Do we want some sort of optimization for constant printf? 99% of the time, we
could parse the string at compile-time. (This sort of optimization is common
for embedded targets.)
If the format string isn't constant, is parsing the string on the GPU really
slower than
efriedma-quic wrote:
(Please move out of "draft" when you think this is ready.)
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
efriedma-quic wrote:
Please fix buildbot failure (it looks like clang/test/CodeGen/ifunc.c is
failing).
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -5751,8 +5751,29 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
,
if (llvm::CallInst *Call = dyn_cast(CI)) {
if (TargetDecl && TargetDecl->hasAttr())
Call->setTailCallKind(llvm::CallInst::TCK_NoTail);
-else if (IsMustTail)
+else if
@@ -707,7 +707,36 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
In a lot of cases, we report_fatal_error because we don't actually expect users
to run into the issues... indicate some internal inconsistency in the compiler,
or some unsupported configuration, or something like that. Because of this,
report_fatal_error prints the
efriedma-quic wrote:
This is roughly what I expected the patch to look like. Maybe consider adding
a couple small wrapper functions around isEmptyRecord/isEmptyField to simplify
the uses (and so we can use a name that indicates why the checks exist).
efriedma-quic wrote:
If you want to modify part of a bitfield unit, you need to load/store the whole
bitfield unit, as computed by the CGRecordLayout. This is true whether you're
modifying an actual field, or padding adjacent to a field. Since any padding
has to be adjacent to a bitfield,
efriedma-quic wrote:
I'm not sure I understand the goal here.
For return-address signing, each function can make its own choice about whether
to sign; the function that's doing the signing is the same function that does
the auth, so it doesn't directly impact any other function. For branch
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/95999
___
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. Please don't forget about the varargs issue, though
https://github.com/llvm/llvm-project/pull/96259
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
I can't think of any obvious reason this would cause timeouts. I mean, you're
adding metadata to a bunch of functions, and if something handles that metadata
inefficiently, things could easily explode. But nothing specific comes to mind.
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
> > Can we restrict this to targets where libm actually modifies errno?
>
> Do you mean it is better to have a function list, which actually modifies
> `errno` ? For example, we should restrict to `__exp10`, but but not a general
> top call `__exp `?
I said targets, not
https://github.com/efriedma-quic approved this pull request.
https://github.com/llvm/llvm-project/pull/94226
___
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/96025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -707,7 +707,38 @@ 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 commented:
Ideally we could identify errno more precisely somehow, but I guess this is
better than nothing.
Can we restrict this to targets where libm actually modifies errno?
How does this interact with StrictFP?
efriedma-quic wrote:
It's not that hard to compute "no-data": non-RecordDecls are never no-data,
RecordDecls are no-data if they don't have a vtable pointer (isDynamicClass()),
and all fields are no-data. We can save it in the CGRecordLayout.
Assuming that's the route we want to go, of
efriedma-quic wrote:
I think some of the overloads for constructing an instruction aren't quite
right: in some cases, we require a non-null insertion-point so we can retrieve
the DataLayout from the insertion-point. (Particularly instructions that have
an explicitly specified alignment.) In
@@ -203,8 +203,15 @@ ABIArgInfo NVPTXABIInfo::classifyArgumentType(QualType Ty)
const {
void NVPTXABIInfo::computeInfo(CGFunctionInfo ) const {
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
- for (auto :
efriedma-quic wrote:
> > couldn't the inverse be true, then - that codegen should ignore if
> > something isZeroSize or not?
>
> Just to clarify, is the suggestion here to remove the special handling of
> `isZeroSize` in the RecordLayoutBuilder?
We currently need to distinguish between empty
@@ -97,9 +102,13 @@ define void @test_vla(i32 %n) nounwind ssp {
; MSVC-X64: callq escape
; MSVC-X64: movq [[SLOT]](%rbp), %rcx
; MSVC-X64: xorq %rbp, %rcx
-; MSVC-X64: callq __security_check_cookie
+; MSVC-X64:movq__security_cookie(%rip), %rax
@@ -5,9 +5,20 @@ declare void @h(ptr, i64, ptr)
efriedma-quic wrote:
Can we use update_llc_test_checks.py for this test?
https://github.com/llvm/llvm-project/pull/95904
___
cfe-commits mailing list
efriedma-quic wrote:
I don't have any context beyond what's written on
https://reviews.llvm.org/D25204 . And at this point, I'm not sure what
compiler we're trying to be compatible with. (I added @erichkeane in case he
remembers.)
https://github.com/llvm/llvm-project/pull/95257
https://github.com/efriedma-quic approved this pull request.
LGTM
Your commit message mentions variables, function pointers, and member function
pointers... is there anything else we need to handle? Null pointers?
Integers?
https://github.com/llvm/llvm-project/pull/92477
efriedma-quic wrote:
That would mean if someone wrote `struct Empty {}; struct Z { Empty a,b,c; }`,
we'd lower it to `{ [3 x i8] }` instead of `{%Empty, %Empty, %Empty}`, which is
a bit ugly. Other than that, sure, I guess we could do that.
https://github.com/llvm/llvm-project/pull/93809
efriedma-quic wrote:
Please don't commit binary files if it isn't absolutely necessary. You can
generate whatever files you need in a RUN line.
https://github.com/llvm/llvm-project/pull/95802
___
cfe-commits
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 %s -fsyntax-only --embed-dir=%S/Inputs -verify=expected,cxx
-Wno-c23-extensions
+// RUN: %clang_cc1 -x c -std=c23 %s -fsyntax-only --embed-dir=%S/Inputs
-verify=expected,c
+#embed
+;
+
+void f (unsigned char x) { (void)x;}
+void g () {}
@@ -2422,6 +2422,10 @@ void ExprEngine::Visit(const Stmt *S, ExplodedNode *Pred,
Bldr.addNodes(Dst);
break;
}
+
+case Stmt::EmbedExprClass:
+ llvm_unreachable("Support for EmbedExpr is not implemented.");
efriedma-quic wrote:
Please
efriedma-quic wrote:
Oh, in this particular case, the issue isn't the computed datasize, it's that
FieldDecl::isZeroSize() returns the wrong result. If that's the case, maybe we
can just change FieldDecl::isZeroSize() to say the field is zero size? So
essentially, we pretend all empty
@@ -8015,6 +8015,26 @@ but do not pass them to the underlying coroutine or pass
them by value.
}];
}
+def CoroStructuredConcurrencyDoc : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+The ``[[clang::coro_structured_concurrency]]`` is a class attribute
https://github.com/efriedma-quic approved this pull request.
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
@@ -8015,6 +8015,26 @@ but do not pass them to the underlying coroutine or pass
them by value.
}];
}
+def CoroStructuredConcurrencyDoc : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+The ``[[clang::coro_structured_concurrency]]`` is a class attribute
efriedma-quic wrote:
For reference, current MSVC has a flag /Ob3 to request more aggressive inlining.
https://github.com/llvm/llvm-project/pull/95406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6853,6 +6853,7 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DI->completeUnusedClass(*CRD);
}
+
efriedma-quic wrote:
Unnecessary whitespace change
@@ -318,6 +318,9 @@ namespace {
if (Diags.hasUnrecoverableErrorOccurred())
return;
+ if (RD->shouldEmitInExternalSource())
efriedma-quic wrote:
Most of the CodeGen code surrounding vtable emission is optimizations.
Specifically, to avoid
@@ -0,0 +1,807 @@
+//===--===//
+//
+// 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:
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction , Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size_t
@@ -2538,6 +2539,205 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction , Value *Ptr, QualType Ty,
+
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction , Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size_t
efriedma-quic wrote:
If we're trying to match MSVC, the amount of inlining MSVC does at /O2 is
probably closer to what clang does at -O2 than -O3. Which is why it was mapped
that way in 015ce0f68f791b3abec4225c1b2e532ce5020174, I think. clang's -O3 is
really aggressive (which tends to look
@@ -318,6 +318,9 @@ namespace {
if (Diags.hasUnrecoverableErrorOccurred())
return;
+ if (RD->shouldEmitInExternalSource())
efriedma-quic wrote:
The way I see it, Sema should have the exact right answer for whether the
vtable is required.
efriedma-quic wrote:
Right, the specification requires splitting the whole structure into chunks; if
we add a special-case for 8-byte structs, we'll just have to throw it away when
we implement the right algorithm.
Also, I'm not sure what the isBuiltinType() check is supposed to handle. It
@@ -325,14 +325,19 @@ Address SparcV9ABIInfo::EmitVAArg(CodeGenFunction ,
Address VAListAddr,
break;
case ABIArgInfo::Ignore:
-return Address(llvm::UndefValue::get(ArgPtrTy), ArgTy, TypeInfo.Align);
+return CGF.EmitLoadOfAnyValue(
+CGF.MakeAddrLValue(
@@ -834,5 +834,4 @@ typedef struct {} empty;
empty empty_record_test(void) {
// CHECK-LABEL: define{{.*}} void @empty_record_test()
return va_arg(the_list, empty);
-// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load ptr, ptr @the_list
efriedma-quic wrote:
Maybe
https://github.com/efriedma-quic approved this pull request.
A couple minor comments; otherwise LGTM
https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic 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
efriedma-quic wrote:
Yes, I think it's just a historical mistake; sin/cos/log/exp were added a very
long time ago, and we weren't as careful about that sort of thing. And nobody
has taken the time to try to cleanup the current defaults.
https://github.com/llvm/llvm-project/pull/94559
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/94346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
What you're implementing in this change doesn't seem like it brings us much
closer to what the document says. I mean, it handles the specific structs in
your testcase, but the algorithm you're using doesn't generalize.
https://github.com/llvm/llvm-project/pull/95257
efriedma-quic wrote:
Can we change the target-independent bits of the tan() implementation in the
backend so it doesn't require each target to explicitly request that tan()
needs to be expanded? It should be possible to adjust the code in
TargetLoweringBase.cpp a bit so FTAN defaults to
@@ -318,6 +318,9 @@ namespace {
if (Diags.hasUnrecoverableErrorOccurred())
return;
+ if (RD->shouldEmitInExternalSource())
efriedma-quic wrote:
Did you mean to change something in ModuleBuilder.cpp?
@@ -318,6 +318,9 @@ namespace {
if (Diags.hasUnrecoverableErrorOccurred())
return;
+ if (RD->shouldEmitInExternalSource())
efriedma-quic wrote:
Maybe this check should be part of DefineUsedVTables()?
@@ -6853,6 +6853,13 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DI->completeUnusedClass(*CRD);
}
+// If we're emitting a dynamic class from the importable module we're
+//
efriedma-quic wrote:
Do you have a reference for the rules you're implementing?
https://github.com/llvm/llvm-project/pull/95257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address
VAListAddr, QualType Ty,
OnStackBlock, "vaargs.addr");
if (IsIndirect)
-return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy,
-
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address
VAListAddr, QualType Ty,
OnStackBlock, "vaargs.addr");
if (IsIndirect)
-return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy,
-
efriedma-quic wrote:
> I don't know much about there intrinsics on ARM, what are the stronger
> guarantees?
The Arm specifies that there's a memory reservation, and you can write whatever
operations you want as long as you don't break that reservation. And the
reservation is usually only a
@@ -6853,6 +6853,13 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DI->completeUnusedClass(*CRD);
}
+// If we're emitting a dynamic class from the importable module we're
+//
@@ -1227,7 +1241,8 @@ void CodeGenModule::EmitDeferredVTables() {
#endif
for (const CXXRecordDecl *RD : DeferredVTables)
-if (shouldEmitVTableAtEndOfTranslationUnit(*this, RD))
+if (shouldEmitVTableAtEndOfTranslationUnit(*this, RD) &&
+
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address
VAListAddr, QualType Ty,
OnStackBlock, "vaargs.addr");
if (IsIndirect)
-return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy,
-
@@ -4777,6 +4783,13 @@ class CodeGenFunction : public CodeGenTypeCache {
/// aggregate type into a temporary LValue.
LValue EmitAggExprToLValue(const Expr *E);
+ enum ExprValueKind { EVK_RValue, EVK_NonRValue };
+
+ /// EmitAggFinalDestCopy - Emit copy of the specified
https://github.com/efriedma-quic commented:
This generally seems fine.
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
@@ -102,12 +98,7 @@ char *test_ptr(char *fmt, ...) {
// N32: [[TMP2:%.+]] = load i64, ptr [[AP_CUR]], align 8
// N32: [[TMP3:%.+]] = trunc i64 [[TMP2]] to i32
// N32: [[PTR:%.+]] = inttoptr i32 [[TMP3]] to ptr
-// N32: store ptr [[PTR]], ptr [[AP_CAST]], align 4
-//
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address
VAListAddr, QualType Ty,
OnStackBlock, "vaargs.addr");
if (IsIndirect)
-return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy,
-
@@ -325,14 +325,19 @@ Address SparcV9ABIInfo::EmitVAArg(CodeGenFunction ,
Address VAListAddr,
break;
case ABIArgInfo::Ignore:
-return Address(llvm::UndefValue::get(ArgPtrTy), ArgTy, TypeInfo.Align);
+return CGF.EmitLoadOfAnyValue(
+CGF.MakeAddrLValue(
https://github.com/efriedma-quic 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
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/83301
___
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/94559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Also, we probably want to specify the interaction between trivial_abi and
value_type here... should trivial_abi imply value_type?
https://github.com/llvm/llvm-project/pull/95004
___
cfe-commits mailing list
efriedma-quic wrote:
> I feel like this is a property that needs to propagate through types
You mean, similar to the way trivial_abi works? That makes sense.
https://github.com/llvm/llvm-project/pull/95004
___
cfe-commits mailing list
@@ -196,12 +196,14 @@ bool AArch64FunctionInfo::needsAsyncDwarfUnwindInfo(
const MachineFunction ) const {
if (!NeedsAsyncDwarfUnwindInfo) {
const Function = MF.getFunction();
+const AArch64FunctionInfo *AFI = MF.getInfo();
// The check got "minsize" is
@@ -214,7 +232,8 @@ declare double @za_shared_callee(double) "aarch64_inout_za"
define double @za_new_caller_to_za_shared_callee(double %x) nounwind noinline
optnone "aarch64_new_za"{
; CHECK-COMMON-LABEL: za_new_caller_to_za_shared_callee:
; CHECK-COMMON: // %bb.0: //
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/84135
___
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/93115
>From 816ceb271c28ff6c4dc05485000deec087674e37 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 23 May 2024 18:38:04 -0700
Subject: [PATCH] Fix codegen of consteval functions returning an empty
efriedma-quic wrote:
lr/sc builtins are extremely fragile: there's no reasonable way for the
compiler to guarantee that the sc is placed in such a way that it will
eventually succeed. (The equivalent intrinsics do exist on ARM, but ARM has
significantly stronger guarantees here. Even then,
efriedma-quic wrote:
I'm not sure messing with the linkage this way will interact well with various
C++ features. In particular, there are various places that check the "language
linkage", which you're not modifying: from the perspective of anything outside
of codegen, these
functions are
@@ -196,12 +196,14 @@ bool AArch64FunctionInfo::needsAsyncDwarfUnwindInfo(
const MachineFunction ) const {
if (!NeedsAsyncDwarfUnwindInfo) {
const Function = MF.getFunction();
+const AArch64FunctionInfo *AFI = MF.getInfo();
// The check got "minsize" is
@@ -214,7 +232,8 @@ declare double @za_shared_callee(double) "aarch64_inout_za"
define double @za_new_caller_to_za_shared_callee(double %x) nounwind noinline
optnone "aarch64_new_za"{
; CHECK-COMMON-LABEL: za_new_caller_to_za_shared_callee:
; CHECK-COMMON: // %bb.0: //
@@ -196,12 +196,14 @@ bool AArch64FunctionInfo::needsAsyncDwarfUnwindInfo(
const MachineFunction ) const {
if (!NeedsAsyncDwarfUnwindInfo) {
const Function = MF.getFunction();
+const AArch64FunctionInfo *AFI = MF.getInfo();
// The check got "minsize" is
@@ -3219,7 +3219,8 @@ void CodeGenModule::EmitVTablesOpportunistically() {
for (const CXXRecordDecl *RD : OpportunisticVTables) {
assert(getVTables().isVTableExternal(RD) &&
"This queue should only contain external vtables");
-if
@@ -6853,6 +6853,13 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DI->completeUnusedClass(*CRD);
}
+// If we're emitting a dynamic class from the importable module we're
+//
@@ -6853,6 +6853,13 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DI->completeUnusedClass(*CRD);
}
+// If we're emitting a dynamic class from the importable module we're
+//
@@ -1830,6 +1830,9 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
,
if (VTable->hasInitializer())
return;
+ if (RD->shouldEmitInExternalSource())
+return;
efriedma-quic wrote:
This check seems like it's at the wrong level; if we
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4656,14 +4656,14 @@ static void InitCatchParam(CodeGenFunction ,
auto catchRD = CatchType->getAsCXXRecordDecl();
CharUnits caughtExnAlignment = CGF.CGM.getClassPointerAlignment(catchRD);
- llvm::Type *PtrTy = CGF.UnqualPtrTy; // addrspace 0 ok
@@ -8287,6 +8289,13 @@ AArch64TargetLowering::LowerCall(CallLoweringInfo ,
SDValue InGlue;
if (RequiresSMChange) {
+
+if (Subtarget->hasSVE()) {
efriedma-quic wrote:
Oh, right, there's also that dimension. I'm not sure I understand the
interaction
efriedma-quic wrote:
llvm::PointerType::getUnqual assumes pointers to addr-space 0 are
"unqualified"... but the discussion on #88182 concluded that doesn't make
sense: the "unqualified" address space is a target-specific choice, and
address-space zero isn't required to have any meaning at
1 - 100 of 898 matches
Mail list logo
