@@ -20,6 +20,12 @@ class RISCVBuiltin :
TargetBuiltin {
let Attributes = [NoThrow, Const] in {
//===--===//
+// Zicsr extension.
+//===--==
@@ -147,6 +147,7 @@ struct ImplicitConversionData {
const TypeDescriptor &FromType;
const TypeDescriptor &ToType;
/* ImplicitConversionCheckKind */ unsigned char Kind;
+ unsigned int BitfieldBits;
efriedma-quic wrote:
Do we have an ABI stability policy
@@ -0,0 +1,61 @@
+// RUN: %clang -fsanitize=implicit-bitfield-conversion -target x86_64-linux -S
-emit-llvm -o - %s | FileCheck %s
--check-prefixes=CHECK,CHECK-BITFIELD-CONVERSION
efriedma-quic wrote:
I'd like to see some testcases that run in C++ mode.
https:
efriedma-quic wrote:
A report from the field: we had an ignorelist that contained
`[cfi-vcall|cfi-nvcall|cfi-icall]`. This was recommended syntax from the
documentation
(https://releases.llvm.org/17.0.1/tools/clang/docs/SanitizerSpecialCaseList.html)...
but it broke with the transition. Thi
efriedma-quic wrote:
CC @llvm/clang-vendors
> I [announced this change on
> discourse](https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666?u=ellishg)
> last year.
"Use glob instead of regex for SpecialCaseLists" doesn't mean anything for
anyone not actively work
efriedma-quic wrote:
See also #80195 (CC @nickdesaulniers).
gcc on aarch64 Linux only supports _Float128, not __float128; this seems like a
bit of a compatibility hazard.
https://github.com/llvm/llvm-project/pull/85070
___
cfe-commits mailing list
cf
efriedma-quic wrote:
The primary problem with allowing flexible arrays alone in structs/unions is
that you end up with a zero-size type. This leads to weird semantic issues
because standard C/C++ doesn't have any provision for zero-size types: pointer
arithmetic, struct layout, and initializa
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/77907
___
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:
Code change looks fine; the regression test needs a few tweaks.
https://github.com/llvm/llvm-project/pull/77907
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -x c -o - %s |
FileCheck %s
+
+typedef struct { struct {} a; } empty;
+
+// CHECK-LABEL: define{{.*}} void @{{.*}}empty_record_t
efriedma-quic wrote:
I think the logic the code is using is that t67 is actually properly aligned:
it's a type with size 8 and alignment 4, so everything is fine. If that's not
right, we should tweak the relevant logic (around line 2104).
Specifically checking whether a type crosses an 8-byte
@@ -3504,6 +3504,47 @@ argument can be of any unsigned integer type.
``__builtin_popcount{,l,ll}`` builtins, with support for other integer types,
such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``.
+``__builtin_clzg`` and ``__builtin_ctzg``
+---
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/83431
___
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 with one minor comment
https://github.com/llvm/llvm-project/pull/83431
___
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/84230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
The code in question is comparing what Sema thinks the size of a variable
should be, versus the size of the variable we're actually emitting into LLVM
IR. So try dumping the value of "Init". If it looks wrong, we need to fix
constant emission. If it's right, probably so
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/77907
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> because we don't yet support non-zero initialization (as described in commit
> [5955a0f](https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f))
I'm confused. We support non-zero init, and there are tests for non-zero init
in that commit.
@@ -700,10 +700,13 @@ class MSBuiltin {
//===--- Variable Argument Handling Intrinsics
===//
//
-def int_vastart : DefaultAttrsIntrinsic<[], [llvm_ptr_ty], [],
"llvm.va_start">;
-def int_vacopy : DefaultAttrsIntrinsic<[], [llvm_ptr_ty, llvm_ptr_t
efriedma-quic wrote:
gcc uses memory, and the ABI standard doesn't explicitly contradict it, so
let's just go with that.
https://github.com/llvm/llvm-project/pull/85394
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
@@ -1069,6 +1069,10 @@ Address X86_32ABIInfo::EmitVAArg(CodeGenFunction &CGF,
auto TypeInfo = getContext().getTypeInfoInChars(Ty);
+ // Empty records are ignored for parameter passing purposes on non-Windows.
+ if (!IsWin32StructABI && isEmptyRecord(getContext(), Ty, true
https://github.com/efriedma-quic requested changes to this pull request.
If you read the code, it should be obvious the pointer is in fact non-null.
Please don't insert null checks into the code just to address static analyzer
false positives.
https://github.com/llvm/llvm-project/pull/86018
_
@@ -1069,6 +1069,10 @@ Address X86_32ABIInfo::EmitVAArg(CodeGenFunction &CGF,
auto TypeInfo = getContext().getTypeInfoInChars(Ty);
+ // Empty records are ignored for parameter passing purposes on non-Windows.
+ if (!IsWin32StructABI && isEmptyRecord(getContext(), Ty, true
@@ -21,3 +21,18 @@ empty empty_record_test(int z, ...) {
__builtin_va_start(list, z);
return __builtin_va_arg(list, empty);
}
+
efriedma-quic wrote:
Please regenerate the CHECK lines with update_cc_test_checks.py.
https://github.com/llvm/llvm-project/pull
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86377
___
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/86377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,69 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+
+
+typedef struct { struct {} a; } empty;
+
+// CHECK-LABEL: define dso_local voi
efriedma-quic wrote:
(This overlaps with #86075, so I'm going to hold off on reviewing this for now.)
https://github.com/llvm/llvm-project/pull/86388
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayType
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
efriedma-quic wrote:
If you implement #86075 like I suggested, the inconsistency here also goes
away, I think: if va_arg queries classifyArgumentType, you get the same result
as argument lowering, so clang becomes self-consistent. (Whether that's
gcc-compatible is a different question...)
ht
efriedma-quic wrote:
Instead of Expr::mayBranchOut, I'd prefer to just unconditionally create the
alloca, then delete it later if it turns out we didn't actually need to emit
the branch. Trying to explicitly compute whether there's a branch out seems
both difficult, and potentially costly for
efriedma-quic wrote:
If we do keep mayBranchOut(), "asm goto" should also be added to the list of
expressions that can branch out. (I think JumpDiagnostics currently forbids
actually branching out in cases that would require a cleanup, but better to be
defensive here.)
https://github.com/llv
efriedma-quic wrote:
Adding attributes to types as type sugar (not part of the canonical type) is
generally problematic: non-canonical types are not reliably preserved
throughout the compiler, particularly in cases involving templates.
Can we use a type qualifier here?
https://github.com/llvm
@@ -12354,21 +12354,31 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_clzl:
case Builtin::BI__builtin_clzll:
case Builtin::BI__builtin_clzs:
+ case Builtin::BI__builtin_clzg:
case Builtin::BI__lzcnt16: // Microsoft variant
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86742
___
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
The one thing I'm worried about here is the possibility that a future C
standard version standardizes a similar extension, but with different semantics
(since we're not using any reserved keywords here). Like I mentioned before
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
arm64x isn't really a "target" in the sense that you can build code for it.
When you're building a C file, it's either arm64, or arm64ec; it can't be
"arm64x". arm64x is just a library format that combines an arm64 library with
an arm64ec library.
So I'm tempted to say
efriedma-quic wrote:
> > Instead of Expr::mayBranchOut, I'd prefer to just unconditionally create
> > the alloca, then delete it later if it turns out we didn't actually need to
> > emit the branch.
>
> I had earlier tried tracking instructions auxiliary to a particular cleanup
> in #83224
>
@@ -2177,7 +2177,8 @@ struct CounterCoverageMappingBuilder
}
void VisitOpaqueValueExpr(const OpaqueValueExpr* OVE) {
-Visit(OVE->getSourceExpr());
+if (const Expr *SE = OVE->getSourceExpr())
efriedma-quic wrote:
I suspect the correct check here is
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -mllvm -emptyline-comment-coverage=false
-fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping
-emit-llvm-only -main-file-name templates.cpp %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++20 -mllvm -emptyline-comment-coverage=fal
efriedma-quic wrote:
Because we're dealing specifically with integers, which are a pretty limited
class, you could consider introducing new types into the type system instead.
Similar to how ext_vector_type works. That's maybe easier than qualifiers in
the sense that the code already deals w
efriedma-quic wrote:
Is this patch ready to merge?
https://github.com/llvm/llvm-project/pull/72197
___
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/86835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
If you think the coroutine codegen thing is something that needs to be
addressed in a followup, can you open a bug for it?
https://github.com/llvm/llvm-project/pull/86923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
efriedma-quic wrote:
I assume the FIXME is referring to some deeper change here? If it were that
easy, the FIXME wouldn't be there in the first place.
CC @zygoloid @rjmccall
https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
efriedma-quic wrote:
https://github.com/llvm/llvm-project/blob/c0f8be4fcfb725d53841d4b17a68685e2a79/clang/lib/CodeGen/CGExpr.cpp#L277
https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
efriedma-quic wrote:
As far as I can tell, the code in question only actually runs for 32-bit x86
targets (it's tied to the old ABI, which was replaced on newer targets). So
there's no point to modifying it.
https://github.com/llvm/llvm-project/pull/85481
_
@@ -2331,6 +2332,11 @@ void CodeGenFunction::EmitVariablyModifiedType(QualType
type) {
type = cast(ty)->getPointeeType();
break;
+case Type::ArrayParameter:
efriedma-quic wrote:
Can we just use the existing "case" for ConstantArray?
https://
@@ -10926,6 +10965,10 @@ QualType ASTContext::mergeTypes(QualType LHS, QualType
RHS, bool OfBlockPointer,
assert(LHS != RHS &&
"Equivalent pipe types should have already been handled!");
return {};
+ case Type::ArrayParameter:
+assert(LHS != RHS &&
+
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/86742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,19 +1105,24 @@ void CodeGenFunction::EmitNewArrayInitializer(
}
// Enter a partial-destruction Cleanup if necessary.
-if (needsEHCleanup(DtorKind)) {
+if (DtorKind) {
+ AllocaTrackerRAII AllocaTracker(*this);
efriedma-quic wrote:
@@ -266,6 +269,54 @@ class alignas(8) EHCleanupScope : public EHScope {
};
mutable struct ExtInfo *ExtInfo;
+ /// Erases auxillary allocas and their usages for an unused cleanup.
+ /// Cleanups should mark these allocas as 'used' if the cleanup is
+ /// emitted, otherwi
@@ -1,4 +1,5 @@
// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - |
FileCheck %s
+// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -emit-llvm -o - | FileCheck
%s
efriedma-quic wrote:
Not sure we need the new RUN line? There shouldn't be any
efriedma-quic wrote:
Try rebasing your patch? If you're unlucky, you might have based your patch on
a bad revision of main (and the buildbot just uses your branch as-is).
https://github.com/llvm/llvm-project/pull/86902
___
cfe-commits mailing list
cf
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
(Please fix the formatting issue before merging)
https://github.com/llvm/llvm-project/pull/86075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6135,6 +6137,79 @@ processImplicitMapsWithDefaultMappers(Sema &S,
DSAStackTy *Stack,
}
}
+namespace {
+/// A 'teams loop' with a nested 'loop bind(parallel)' or generic function
+/// call in the associated loop-nest cannot be a 'parallel for'.
+class TeamsLoopChecker fi
efriedma-quic wrote:
We can't just skip compiling part of the code because it's infinite recursion.
It's not clear to me there's really a bug here to solve. Maybe the compiler
can detect simple cases of infinite recursion and print a warning.
https://github.com/llvm/llvm-project/pull/87310
__
@@ -628,7 +628,7 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) {
// Create, but don't insert, the new block.
Dest = JumpDest(createBasicBlock(D->getName()),
- EHScopeStack::stable_iterator::invalid(),
+ EHScopeStack::stable_i
@@ -628,7 +628,7 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) {
// Create, but don't insert, the new block.
Dest = JumpDest(createBasicBlock(D->getName()),
- EHScopeStack::stable_iterator::invalid(),
+ EHScopeStack::stable_i
efriedma-quic wrote:
> > I'm skeptical this actually makes sense in its current form. LLVM
> > internally has a thing it calls a basic block, but what exactly counts is,
> > to some extent, machine-specific, and can change from version to version.
>
> I guess regardless of whether we call it B
efriedma-quic wrote:
One possibility would be to use a type qualifier? It has basically the kind of
properties you want... the underlying type is still there, and places that
strip qualifiers will automatically do the right thing in a lot of cases. It
might require a bit more work to handle
https://github.com/efriedma-quic commented:
I don't really like the whole "sufficiently simple function" thing. It seems
fragile. You should be able to just take a arbitrary internal varargs
function, rewrite its signature to take a va_list argument, rewrite calls to
va_start to make a copy
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,701 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apache
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/81298
>From d59c262b31937fdd2b907ec11d7f08e4a385007c Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Fri, 9 Feb 2024 21:55:03 +0330
Subject: [PATCH 1/4] [clang] Support `__is_trivially_copyable(int()&)==fal
https://github.com/efriedma-quic commented:
Do we need to add handling for `new int[](co_await foo())`
(CodeGenFunction::EmitNewArrayInitializer)?
https://github.com/llvm/llvm-project/pull/80698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -627,9 +627,11 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) {
if (Dest.isValid()) return Dest;
// Create, but don't insert, the new block.
+ // FIXME: We do not know `BranchInExprDepth` for the destination and
currently
+ // emit *all* the BranchInExpr
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/80698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
// observed to be unnecessary.
if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit);
}
-
-LValue elementLV = CGF.MakeAddrLValue(
-Address(e
efriedma-quic wrote:
Looks like a bug in the SPARC backend.
https://github.com/llvm/llvm-project/pull/73176#pullrequestreview-1811677691
indicated that atomic expansion was working correctly for all backends, but I
guess it isn't working correctly on SPARC.
https://github.com/llvm/llvm-proj
@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
// observed to be unnecessary.
if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit);
}
-
-LValue elementLV = CGF.MakeAddrLValue(
-Address(e
efriedma-quic wrote:
> IIUC you're suggesting movint the TBAA data origination from CodeGen into
> (probably) Sema and/or TargetInfo and then deriving the LLVM info in CodeGen
> from that. I.e. keep once source of truth, but move where it is?
Right; move the core computation to AST, and then t
https://github.com/efriedma-quic commented:
We could consider keeping the warning group, not actually guarding any warning,
so we don't warn on `-Wno-gnu-binary-literal`.
Otherwise looks fine.
https://github.com/llvm/llvm-project/pull/81658
___
cfe-c
efriedma-quic wrote:
I can't tell what you're trying to fix here. Is this fixing a crash? Or is
the check redundant? Or is it necessary for some followup change you want to
make?
https://github.com/llvm/llvm-project/pull/81669
___
cfe-commits mail
@@ -3014,6 +3014,16 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction &CGF,
Address VAListAddr,
ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE,
/*isNamedArg*/false);
+ // Empty records are ignored for parameter pas
efriedma-quic wrote:
This seems fine.
In some cases, we could maybe prove certain bytes are padding regardless of the
current representation, but probably not worth the effort to implement.
https://github.com/llvm/llvm-project/pull/84370
___
cfe-comm
https://github.com/efriedma-quic commented:
This is clearly not what we want long-term. Either clang or LLVM should have
better heuristics based on the actual values being stored; the syntax used at
the C level shouldn't affect codegen.
That said, reverting the change with a carveout for the
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/75481
___
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 a bit concerned about the lack of C++ testcases, since you're making
changes to some C++-only codepaths.
https://github.com/llvm/llvm-project/pull/75481
___
cfe-commits mailing list
cfe-commits@lists.llv
@@ -5571,11 +5571,52 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const
BinaryOperator *E) {
break;
}
-RValue RV = EmitAnyExpr(E->getRHS());
+llvm::Value *Previous = nullptr;
efriedma-quic wrote:
Can we de-duplicate this code with th
efriedma-quic wrote:
The way LLVM backend works in general is that if an integer is smaller than a
register, when type legalization converts that to a larger integer, the high
bits are undefined. This generally doesn't cause any issues because nothing
can actually observe those bits. Your an
@@ -5571,11 +5571,52 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const
BinaryOperator *E) {
break;
}
-RValue RV = EmitAnyExpr(E->getRHS());
+llvm::Value *Previous = nullptr;
efriedma-quic wrote:
Sure, if you want to leave the larger
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4655,6 +4655,13 @@ void CodeGenFunction::EmitCallArg(CallArgList &args,
const Expr *E,
return emitWritebackArg(*this, args, CRE);
}
+ // If an argument is an array paramter expression being passed through. Emit
+ // the argument to a temporary and pass the tempora
@@ -1126,6 +1126,7 @@ class ConstExprEmitter :
case CK_NonAtomicToAtomic:
case CK_NoOp:
case CK_ConstructorConversion:
+case CK_HLSLArrayRValue:
efriedma-quic wrote:
We shouldn't accept CK_HLSLArrayRValue casts here (or if we do, we need to do
@@ -10900,6 +10936,10 @@ QualType ASTContext::mergeTypes(QualType LHS, QualType
RHS, bool OfBlockPointer,
assert(LHS != RHS &&
"Equivalent pipe types should have already been handled!");
return {};
+ case Type::ArrayParameter:
+if (RHS != LHS)
-
https://github.com/efriedma-quic commented:
This seems like the right direction.
https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1442,6 +1445,7 @@ static bool castPreservesZero(const CastExpr *CE) {
case CK_BitCast:
case CK_ToUnion:
case CK_ToVoid:
+ case CK_HLSLArrayRValue:
efriedma-quic wrote:
Probably should be false, like other lvalue-to-rvalue casts?
https://github.com/
@@ -500,6 +500,7 @@ ComplexPairTy ComplexExprEmitter::EmitCast(CastKind CK,
Expr *Op,
case CK_NoOp:
case CK_LValueToRValue:
case CK_UserDefinedConversion:
+ case CK_HLSLArrayRValue:
efriedma-quic wrote:
The result of an CK_HLSLArrayRValue can't be a co
@@ -2231,7 +2231,8 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
case CK_UserDefinedConversion:
return Visit(const_cast(E));
- case CK_NoOp: {
+ case CK_NoOp:
+ case CK_HLSLArrayRValue: {
efriedma-quic wrote:
It shouldn't be possible to
201 - 300 of 1669 matches
Mail list logo
