@@ -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 scheme
@@ -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 = dyn_cast_or_null(Base
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if (!
@@ -4917,6 +4917,9 @@ foreach i = {1-31} in
def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
HelpText<"Reserve the x"#i#" register (AArch64/RISC-V only)">;
+def mlr_for_calls_only : Flag<["-"], "mlr-for-calls-only">,
Group,
efriedma-quic wrote:
Name
efriedma-quic wrote:
The question is, if LTO merges two bitcode modules together with different
settings for the flag, how do you want the backend to behave? Usually you want
it to just continue to apply to the same functions it would have without LTO;
the only way to represent that is a func
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if (!
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if (!
@@ -137,6 +137,16 @@ bool isEmptyField(ASTContext &Context, const FieldDecl
*FD, bool AllowArrays,
bool isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays,
bool AsIfNoUniqueAddr = false);
+/// isEmptyFieldForLayout - Return true iff the field i
@@ -1,7 +1,17 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
// PR4390
struct sysfs_dirent {
- union { struct sysfs_elem_dir {} s_dir; };
+ union { struct sysfs_elem_dir { int x; } s_dir; };
unsi
@@ -185,6 +203,18 @@ CALL_AO(PackedMembers)
// CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1
{{.*}}i64 16, i1 {{.*}})
// CHECK: ret ptr
+// WithEmptyField copy-assignment:
+// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}}
dereferenceable({
efriedma-quic wrote:
The usual mechanism for emitting deferred definitions involves
CodeGenModule::EmitDeferred(): declarations get added to the list by
addDeferredDeclToEmit(), then it goes through to emit all the declarations on
the list. So it's a matter of making sure the resolver ends up
https://github.com/efriedma-quic approved this pull request.
The updated approach makes sense, I think.
Please check that AArch64TargetLowering::LowerRETURNADDR works correctly when
LR is reserved; I think it should just work, but I'm not completely sure.
Otherwise LGTM
https://github.com/llv
https://github.com/efriedma-quic approved this pull request.
LGTM
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
https://github.com/efriedma-quic edited
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
@@ -1,7 +1,19 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-linux-gnu -o - | FileCheck %s
--check-prefixes=CHECK,EMPTY
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-windows-msvc -o - | FileCheck
%s
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/98451
___
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/98451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -152,7 +152,7 @@ class ARMTargetCodeGenInfo : public TargetCodeGenInfo {
diag::warn_target_unsupported_branch_protection_attribute)
<< Arch;
} else {
- BPI.setFnAttributes(*Fn);
+ setBranchProtectionFnAttributes(BPI, (*Fn
@@ -310,6 +310,41 @@ bool CodeGen::isEmptyRecord(ASTContext &Context, QualType
T, bool AllowArrays,
return true;
}
+bool CodeGen::isEmptyFieldForLayout(const ASTContext &Context,
+const FieldDecl *FD) {
+ if (FD->isZeroLengthBitField(Con
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/98525
___
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.
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:
> max aligment [...] LLVM Verifier accepts is 2^14
The verifier limit in most places is 2^32. It looks like 2^14 is specifically
for ByVal. And there isn't really any good reason for that limit; it was
arbitrarily chosen in b567e3ffb0, nearly two decades ago, and could e
efriedma-quic wrote:
(The relevant bitfield is was renamed to MemAlign, and is now in
llvm/include/llvm/CodeGen/TargetCallingConv.h)
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
efriedma-quic wrote:
Does this affect the generated IR in some existing case? If it does, can you
include a regression test in clang/test/CodeGen?
https://github.com/llvm/llvm-project/pull/98668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic commented:
>> How does this interact with StrictFP?
> I don't think it related to StrictFP, because we only care whether the global
> variable errno is modified? which may bring in alias to other global
> variable. As now the type of errno is int, so we record
@@ -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
-check-prefixes=CHECK,
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,34 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
efriedma-quic wrote:
The size of ArgFlagsTy is, as far as I can tell, basically irrelevant: it's
only used as part of computing the calling convention in isel. I don't think
anyone will notice if it's a few bytes larger.
The non-byval alignment limit was last adjusted in
https://reviews.llvm
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
efriedma-quic wrote:
It's used in the same ASTContext code that's modified by this patch. Probably
fine to adjust it fo
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/98832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6106,11 +6111,14 @@ void CodeGenModule::emitIFuncDefinition(GlobalDecl GD) {
Aliases.push_back(GD);
- llvm::Type *DeclTy = getTypes().ConvertTypeForMem(D->getType());
- llvm::Type *ResolverTy = llvm::GlobalIFunc::getResolverFunctionType(DeclTy);
+ // The resolver mig
https://github.com/efriedma-quic approved this pull request.
Not what I was expecting, but this works, sure. LGTM.
https://github.com/llvm/llvm-project/pull/98832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
efriedma-quic wrote:
There are two ways we could analyze, this, I think:
- EmitVAArg is doing something which disagrees with the classification done by
classifyArgumentType, so that's a bug in EmitVAArg.
- classifyArgumentType is returning a malformed value; EmitVAArg should assert
that it nev
efriedma-quic wrote:
> BTW, I think the limitation I'm hitting is introduced by
> https://reviews.llvm.org/D121898 .
The limitation existed before that; we just miscompiled instead of reporting an
error.
https://github.com/llvm/llvm-project/pull/98629
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/90547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1144,11 +1167,13 @@ bool MicrosoftCXXABI::classifyReturnType(CGFunctionInfo
&FI) const {
if (!RD)
return false;
- bool isTrivialForABI = RD->canPassInRegisters() &&
- isTrivialForMSVC(RD, FI.getReturnType(), CGM);
-
// MSVC always returns
https://github.com/efriedma-quic commented:
Maybe we should just be testing if the copy-assignment operator is deleted?
For reference, MSVC also returns the following indirectly:
```
struct Test
{
int x;
Test& operator=(const Test&) = delete;
};
Test foo();
Test test(Test x)
{
return
@@ -908,6 +908,74 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/90702
___
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:
This looks correct.
I'd expect regression tests for the autoupgrade, and a test that clang isn't
generating the alignment markings anymore.
https://github.com/llvm/llvm-project/pull/90702
___
cfe-commits ma
@@ -5387,6 +5387,14 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
return Res;
}
+ // AArch64 data layout upgrades.
+ if (T.isAArch64()) {
+// Add "-Fn32"
+if (!DL.contains("-Fn32"))
+ Res.append("-Fn32");
efri
@@ -5387,6 +5387,14 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
return Res;
}
+ // AArch64 data layout upgrades.
+ if (T.isAArch64()) {
+// Add "-Fn32"
+if (!DL.contains("-Fn32"))
+ Res.append("-Fn32");
efri
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -emit-llvm < %s
efriedma-quic wrote:
Can you integrate this test into some existing file that's testing something
similar?
Please leave the bug number in a comment: something like `//GH88917`.
Please use FileCheck CHECK line
@@ -5702,13 +5702,16 @@ CodeGenModule::getLLVMLinkageVarDefinition(const
VarDecl *VD) {
static void replaceUsesOfNonProtoConstant(llvm::Constant *old,
llvm::Function *newFn) {
// Fast path.
- if (old->use_empty()) return;
+ if (old
efriedma-quic wrote:
Please add a testcase for i1/i2 (which are the only cases where this actually
matters).
https://github.com/llvm/llvm-project/pull/90845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -908,6 +908,72 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
https://github.com/efriedma-quic approved this pull request.
Please fix clang-format warnings. Otherwise LGTM
https://github.com/llvm/llvm-project/pull/90845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/efriedma-quic commented:
I'm a little unhappy with the duplicated logic between checkFunctionCallABI and
checkFunctionABI; is there some way we can unify? Even if it doesn't actually
reduce the code duplication very much, it would be helpful to clarify that both
paths are c
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90066
___
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.
Please fix the commit message before you merge; otherwise LGTM
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
efriedma-quic wrote:
Burying this check in the middle of CodeGen seems error-prone: when we add new
features in the future, someone is going to have to dig up this code. Can we
put this in on of the target feature tables, like in AArch64TargetParser.h?
If I'm understanding correctly, the issu
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1131,13 +1132,18 @@ static bool isTrivialForMSVC(const CXXRecordDecl *RD,
QualType Ty,
return false;
if (RD->hasNonTrivialCopyAssignment())
return false;
+ if (RD->needsImplicitCopyAssignment() && !RD->hasSimpleCopyAssignment())
efriedma-quic wr
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
@@ -908,6 +908,69 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool HasEmptyBody) {
+ if (CGM.getCode
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -emit-llvm < %s
efriedma-quic wrote:
Have you seen https://llvm.org/docs/TestingGuide.html#regression-test-structure
?
If you have any ideas for improving the documentation, please let me know (or
better, propose a patch; it
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/90602
___
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:
LG
https://github.com/llvm/llvm-project/pull/90602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -518,6 +518,16 @@ class TargetInfo : public TransferrableTargetInfo,
/// getInt128Align() - Returns the alignment of Int128.
unsigned getInt128Align() const { return Int128Align; }
+ /// getBitIntAlign/Width - Return aligned size of '_BitInt' and
+ /// 'unsigned _BitI
@@ -1674,4 +1679,4 @@ void RenderScript64TargetInfo::getTargetDefines(const
LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__RENDERSCRIPT__");
AArch64leTargetInfo::getTargetDefines(Opts, Builder);
-}
+
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Which email address do you want the commit associated with? The GitHub "squash
and merge" button wants to attribute it to your "sonosphere.com" address, but
it looks like the commits themselves are using an "apple.com" address.
https://github.com/llvm/llvm-project/pull/90
@@ -3730,6 +3730,12 @@ def warn_gnu_inline_cplusplus_without_extern : Warning<
"'gnu_inline' attribute without 'extern' in C++ treated as externally"
" available, this changed in Clang 10">,
InGroup>;
+def warn_sme_streaming_mode_change_no_sve : Warning<
+ "function requ
@@ -221,6 +224,15 @@ def : Pat<(AArch64_smstop (i32 svcr_op:$pstate), (i64
/*AArch64SME::Always*/0)),
(MSRpstatesvcrImm1 svcr_op:$pstate, 0b0)>;
+// Pseudo to insert cfi_offset/cfi_restore instructions. Used to save or
restore
+// the streaming value of VG around
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/90702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1480,11 +1480,11 @@ AArch64leTargetInfo::AArch64leTargetInfo(const
llvm::Triple &Triple,
void AArch64leTargetInfo::setDataLayout() {
if (getTriple().isOSBinFormatMachO()) {
if(getTriple().isArch32Bit())
- resetDataLayout("e-m:o-p:32:32-i64:64-i128:128-n32:64-S12
efriedma-quic wrote:
I'm worried if we add a whole new series of math intrinsics without adding the
corresponding constrained intrinsics, it's going to be confusing for anyone
trying to understand how math intrinsics work. Why does tan exist, but not
constrained tan?
`tan` is defined basical
@@ -2239,6 +2239,20 @@ The semantics are as follows:
}];
}
+def ARMInterruptSaveFPDocs : Documentation {
+let Category = DocCatFunction;
+ let Heading = "interrupt_save_fp (ARM)";
+ let Content = [{
+Clang supports the GNU style ``__attribute__((interrupt_save_fp("TYPE
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/91281
None
>From 5a5512aa5a84e2c89efd9e9ade043061d73d25fb Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Fri, 3 May 2024 21:13:32 -0700
Subject: [PATCH] [Arm64EC] Fix compilation of arm_acle.h
---
clang/lib
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/91281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -518,6 +518,16 @@ class TargetInfo : public TransferrableTargetInfo,
/// getInt128Align() - Returns the alignment of Int128.
unsigned getInt128Align() const { return Int128Align; }
+ /// getBitIntAlign/Width - Return aligned size of '_BitInt' and
+ /// 'unsigned _BitI
@@ -1774,6 +1774,18 @@ llvm::Constant
*ConstantEmitter::emitForMemory(CodeGenModule &CGM,
return Res;
}
+ if (const auto *BIT = destType->getAs()) {
+if (BIT->getNumBits() > 128) {
+ // Long _BitInt has array of bytes as in-memory type.
+ ConstantAggregat
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/91364
___
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:
Maybe add a helper somewhere to check "is this type a bitint wider than 128
bits"?
https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
@@ -5348,6 +5348,13 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
return llvm::UndefValue::get(ArgTy);
}
+ if (const auto *BIT = Ty->getAs()) {
+if (BIT->getNumBits() > 128) {
efriedma-quic wrote:
This seems a little fragile; specifi
efriedma-quic wrote:
> It seems to me this is a case where we're trying to work -around an llvm bug?
> Should we just be fixing that instead?
You mean, revert https://reviews.llvm.org/D86310 ? Making any changes in LLVM
here is painful; I'd rather not revisit that. CC @hvdijk @rnk
https://g
efriedma-quic wrote:
I don't think FPGA folks will run into any practical issue with this; this only
impacts the in-memory types, and backends shouldn't really be using in-memory
types for anything anyways.
https://github.com/llvm/llvm-project/pull/91364
___
@@ -1950,8 +1950,22 @@ ConstantLValueEmitter::tryEmitBase(const
APValue::LValueBase &base) {
if (D->hasAttr())
return CGM.GetWeakRefReference(D).getPointer();
-if (auto FD = dyn_cast(D))
- return CGM.GetAddrOfFunction(FD);
+if (auto FD = dyn_cast(D)) {
https://github.com/efriedma-quic commented:
Is it possible you could put this code into CompleteExternalDeclaration(),
instead of writing it out in every place that can refer to the address of a
function?
https://github.com/llvm/llvm-project/pull/91310
_
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/91310
___
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/91384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
https://github.com/efriedma-quic commented:
At first glance, making a separate ABI seemed weird, but I guess it's pretty
different from the normal SystemZ ABI.
https://github.com/llvm/llvm-project/pull/91384
___
cfe-commits mailing list
cfe-commits@li
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
@@ -529,9 +529,325 @@ bool SystemZTargetCodeGenInfo::isVectorTypeBased(const
Type *Ty,
return false;
}
+//===--===//
+// z/OS XPLINK ABI Implementation
+//===
efriedma-quic wrote:
> I didn't want the current set of changes to go stale.
How many changes are we talking about here? If it's just the tan() ones,
that's fine; it probably makes sense to land constrained-tan separately anyway.
https://github.com/llvm/llvm-project/pull/90276
___
https://github.com/efriedma-quic approved this pull request.
Okay. I mostly just want to make sure the plan isn't "land all the intrinsics
from the RFC, then eventually investigate the constrained intrinsics".
LGTM
https://github.com/llvm/llvm-project/pull/90276
__
efriedma-quic wrote:
You're suggesting we should fork ConvertTypeForMem into two functions? So
there's actually three types: the "register" type, the "load/store" type, and
the "in-memory" type. I guess that makes sense from a theoretical perspective,
but... as a practical matter, I'm not su
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90602
___
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
@@ -0,0 +1,14 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple aarch64-none-elf \
+// RUN: -O2 \
+// RUN: -emit-llvm -fexperimental-max-bitint-width=1024 -o - %s | FileCheck
%s
efriedma-quic wrote:
Can we integrate this into some existing t
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/91692
Make sure we count the anonymous union as an initialized field, so we properly
construct the AST.
Included bonus testcase Test3, which shows a remaining gap: an anonymous union
can contain a partially ini
@@ -0,0 +1,14 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple aarch64-none-elf \
+// RUN: -O2 \
+// RUN: -emit-llvm -fexperimental-max-bitint-width=1024 -o - %s | FileCheck
%s
efriedma-quic wrote:
Digging a bit into the history, I found cl
901 - 1000 of 1819 matches
Mail list logo
