efriedma-quic wrote:
> What about the case I have mentioned in https://godbolt.org/z/vdhGbvj6W ?
That test doesn't really prove anything useful. The zeroing of a0 doesn't have
any ABI significance: "struct s12" doesn't have any data in it, so the caller
can't use the value in a0 for
https://github.com/efriedma-quic approved this pull request.
LGTM
I meant, at the beginning of X86_32ABIInfo::computeInfo there's a chain of if
statements that set up the properties of different calling conventions, and
maybe some bits could be set there. If you don't think that makes sense,
https://github.com/efriedma-quic commented:
If I'm understanding correctly, the way this currently works is that you do
normal field layout, then if you discover that the actual offset of a field is
less than the offset normal field layout would produce, you assume the struct
is packed. This
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/93267
___
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
efriedma-quic wrote:
> gcc does ignore the empty array case for assigning argument registers in C++.
> Compare the two cases here https://godbolt.org/z/j4WP89rE8
Oh, you're right, I didn't actually do any testing myself, I was just assuming
@svs-quic did the right test.
So I guess the
https://github.com/efriedma-quic commented:
It looks like MSVC also applies this rule to fastcall.
Maybe put a boolean in the "state" to try to group together the code for
specific conventions, instead of directly checking the CC.
https://github.com/llvm/llvm-project/pull/97939
efriedma-quic wrote:
The current spec language is:
> Empty structs or union arguments or return values are ignored by C compilers
> which support them as a non-standard extension. This is not the case for C++,
> which requires them to be sized types.
So empty structs in C are ignored, empty
efriedma-quic wrote:
Oh, hmm, I see.
Maybe the right strategy here is to delay attaching the resolver to the ifunc
until the end of the translation unit, when we know the definition is already
emitted. That way, it should already have the right attributes. (We already
do some delayed
efriedma-quic wrote:
Please make sure you have a testcase for computing the difference between two
blockaddresses (`void g(int*); int f() { static int x = &&
A:g();B:return x; }`). Not sure how you should handle that case.
https://github.com/llvm/llvm-project/pull/97647
https://github.com/efriedma-quic approved this pull request.
LGTM
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
efriedma-quic wrote:
Probably you want a dedicated codepath for computing the right kcfi type for
resolvers.
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
efriedma-quic wrote:
Please add a test for `struct X { int x[0]; };`.
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
To the extent that EvaluateAsRValue handles LValues, FastEvaluateAsRValue
should also handle them, sure. I'm suspicious of the fact that
EvaluateAsRValue is doing this conversion in the first place, but I guess this
pull request isn't the place to address that.
Given
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
efriedma-quic wrote:
I'm concerned that we're calling EvaluateKnownConstInt on an lvalue; that might
indicate there's something wrong with the AST. Usually there should be an
lvalue-to-rvalue cast somewhere.
https://github.com/llvm/llvm-project/pull/97146
efriedma-quic wrote:
The only place the standard requires padding to be zero-initialized is in
"default initialization", which only applies to members which don't have an
initializer. So, for example, if you have `struct X { int x; char y; } z =
{1};`, none of the padding is required to be
efriedma-quic wrote:
If there's some subset of cases that's easy to diagnose, like SSE registers
without SSE, maybe we can do that. I mostly care that we don't write a bunch of
code to check complicated edge cases, like trying to diagnose if you're using
too many registers.
efriedma-quic wrote:
What exactly does it mean for a constraint to conflict with a feature? The
only thing I can think of is if it somehow involves a register class that
doesn't exist on the target with the current set of target features. I guess
we could try to diagnose that, but I'm not
https://github.com/efriedma-quic commented:
We already have `-Wnan-infinity-disabled`, which I think is sufficient on the
warning side? Haven't checked carefully to see what cases it covers.
https://github.com/llvm/llvm-project/pull/96659
___
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
@@ -47,6 +47,8 @@
(defined(__cplusplus) && __cplusplus >= 201103L) ||
\
(__STDC_HOSTED__ && defined(_AIX) && defined(_ALL_SOURCE))
#undef DECIMAL_DIG
+#undef INFINITY
efriedma-quic wrote:
The define guarding the undefs
efriedma-quic wrote:
I mean, this is conceptually fine as far as it goes, but I'm not sure where we
actually want to use it. As noted on the other PRs,
llvm.used/llvm.global_ctors/llvm.global_dtors don't really want a flat
address-space. The "address-space" for llvm.used, and for the
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
efriedma-quic wrote:
To clarify for anyone else looking at this... there are three families of LUTI
instructions: one uses NEON registers, one uses SVE registers, and one uses SME
registers. This patch is just the variant that uses NEON registers.
efriedma-quic wrote:
I don't see any issues with the code. I'd prefer if we has a
TYSan-instrumented bootstrap build of LLVM before we merge this, so we're
confident this doesn't cause any unexpected issues.
https://github.com/llvm/llvm-project/pull/76612
efriedma-quic wrote:
If you want to push this forward, start a Discourse thread (discourse.llvm.org)
with a writeup of the proposal. Including an expanded rationale for why we
want this.
See also https://clang.llvm.org/get_involved.html
https://github.com/llvm/llvm-project/pull/92499
efriedma-quic wrote:
I don't think I like this approach:
- This seems like an easy way to unintentionally pass state between different
compilations.
- It seems very easy to try to use this API during LTO, and have it do nothing.
- I'm pretty sure this breaks existing workflows involving
efriedma-quic wrote:
> Or, if we do need to preserve bitcode compat, how to best achieve it? Perhaps
> we convert them into inline-asm in the bitcode upgrader?
Really, the question is whether we plan to completely drop support for the
x86_mmx type (including inline asm operands/results). If
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
efriedma-quic wrote:
For CGExprConstant, the code is checking "empty" in the sense of whether
there's a corresponding LLVM field. So almost certainly needs changes. Not
sure how that isn't causing test failures; maybe there's missing test coverage.
For CGClass, it's not directly tied to the
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()?
101 - 200 of 1033 matches
Mail list logo
