https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/83313
___
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/83313
___
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/82922
___
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:
Whitespace is weird in a few places; otherwise looks fine.
https://github.com/llvm/llvm-project/pull/82922
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
Oh, I should have caught that when reviewing. (I thought I checked the test
was doing the right thing when I looked at it, but I guess I'm misremembering.)
Probably need to mark the intrinsic CustomTypeChecking, then make the code in
SemaChecking explicitly perform
https://github.com/efriedma-quic commented:
If you run into issues using normal integer ops, please file bugs. Most people
aren't going to hand-tune their code like this; builtins like this are at best
an ugly workaround.
That said, I guess I'm not strongly against adding a backdoor to force
@@ -10737,6 +10752,43 @@ SDValue
PPCTargetLowering::LowerINTRINSIC_WO_CHAIN(SDValue Op,
return DAG.getRegister(PPC::X13, MVT::i64);
return DAG.getRegister(PPC::R2, MVT::i32);
+ case Intrinsic::ppc_rldimi: {
+uint64_t SH = Op.getConstantOperandVal(3);
+
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/82968
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout = Context.getASTRecordLayout(RD);
+const CGRecordLayout = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field_iterator i
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout = Context.getASTRecordLayout(RD);
+const CGRecordLayout = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field_iterator i
https://github.com/efriedma-quic approved this pull request.
I'm not sure there's really much point to passing around a const reference to a
CGRecordLowering; all the uses are in one file, so const-correctness doesn't
seem to help that much.
But if you want to do it this way, that's fine;
efriedma-quic wrote:
This seems like it messes up the metadata in a different way: we have no
representation of the bitfield at all, so it looks like it's padding.
I think we want to treat multiple adjacent bitfields as a single "field". So
NamedBitfields from the testcase would have three
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/82400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please fix your GitHub settings so your email address is public. Looks like
the bot didn't trigger for some reason; see
https://github.com/llvm/llvm-project/pull/82429#issuecomment-1955214651 for the
normal message.
https://github.com/llvm/llvm-project/pull/82359
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -886,28 +886,16 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
,
} else {
// Assume pre-ARMv6 doesn't support unaligned accesses.
//
-// ARMv6 may or may not support unaligned accesses depending on the
-// SCTLR.U bit, which is
efriedma-quic wrote:
Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the memory
in question is configured as "normal" memory. Almost all operating systems do
in fact configure their registers/memory this way, but on baremetal it's not
really a safe assumption. Changing
efriedma-quic wrote:
Missing semantic analysis. Since the signature is unspecified in Builtin.td,
you have to check that there's one argument, and that argument is an integer.
That code should go in SemaChecking.cpp.
You can leave constant evaluation to a followup, sure.
@@ -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(
-
efriedma-quic wrote:
> If we ignore that design and run functions through the block splitting
> unnecessarily, we win a combinatorial increase in required testing, a
> decrease in emitted code quality (spurious extra functions), an inability to
> pattern match on fprintf->vfprintf style code
https://github.com/efriedma-quic approved this pull request.
LGTM
Note you can get a similar crash using `enum x { X = (__uint128_t)(1<<64) };`.
I'm a little surprised we haven't run into this before C23.
https://github.com/llvm/llvm-project/pull/81760
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/81849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> > 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 of that
https://github.com/efriedma-quic approved this pull request.
LGTM
(It feels a little weird that the types in the clang AST don't actually match
the LLVM builtin, but I guess it's not likely to actually cause any issues.)
https://github.com/llvm/llvm-project/pull/81669
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
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
___
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
@@ -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(
-
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.
@@ -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(
-
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
@@ -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
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
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
@@ -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:
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
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
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
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
@@ -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(),
+
@@ -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(),
+
efriedma-quic wrote:
If I understand correctly, a "lifetime-extended" cleanup deals with the case of
a temporary whose lifetime continues beyond the expression. In other words, it
has different lifetimes depending on how you exit the expression: if the
variable's lifetime begins, it lasts
efriedma-quic wrote:
It's generally not a good idea to use sugar to represent constructs that are
semantically significant: anything that uses the canonical type will throw it
away. We try to avoid throwing away sugar in most cases, but we aren't always
successful.
It's possible there are
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/80465
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,27 @@
+// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s
+
+// Decoding the attribute does not work on big-endian platforms currently
+// XFAIL: target=s390x-{{.*}}
efriedma-quic wrote:
LLVM tests use
@@ -1808,12 +1808,24 @@ struct CounterCoverageMappingBuilder
}
}
+private:
+ static bool evaluateConstantCondition(const Expr *Condition) {
+if (const auto *Expr = dyn_cast(Condition))
+ return Expr->getResultAsAPSInt().getExtValue();
+
+if (const auto
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/79502
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -945,48 +950,77 @@ static bool
canEmitInitWithFewStoresAfterBZero(llvm::Constant *Init,
/// For inits that canEmitInitWithFewStoresAfterBZero returned true for, emit
/// the scalar stores that would be required.
-static void emitStoresForInitAfterBZero(CodeGenModule ,
-
@@ -945,48 +950,77 @@ static bool
canEmitInitWithFewStoresAfterBZero(llvm::Constant *Init,
/// For inits that canEmitInitWithFewStoresAfterBZero returned true for, emit
/// the scalar stores that would be required.
-static void emitStoresForInitAfterBZero(CodeGenModule ,
-
https://github.com/efriedma-quic commented:
It's not clear to me this is actually consistently profitable if the computed
offset is small. If we have to emit a memset starting at a weird offset, the
code might get worse overall. (e.g. on x86, a memset of 32 bytes is three
instructions; a
@@ -1209,8 +1301,21 @@ static void emitStoresForConstant(CodeGenModule ,
const VarDecl ,
// If the initializer is all or mostly the same, codegen with bzero / memset
// then do a few stores afterward.
if (shouldUseBZeroPlusStoresToInitialize(constant, ConstantSize)) {
-
@@ -1010,6 +1010,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable,
IntrWillReturn] in {
def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>,
llvm_anyint_ty]>;
def int_sin : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
def
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/79948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1010,6 +1010,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable,
IntrWillReturn] in {
def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>,
llvm_anyint_ty]>;
def int_sin : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
def
https://github.com/efriedma-quic requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/79948
___
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/79948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Also, please fix the title so it isn't prefixed with "[libc++]"; the intent is
for this to be used in libc++, but it's proposing a clang intrinsic.
https://github.com/llvm/llvm-project/pull/75371
___
cfe-commits mailing list
@@ -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
@@ -0,0 +1,556 @@
+// RUN: mkdir -p %t
+// RUN: %clang++ %s -o %t/run
+// RUN: %t/run
efriedma-quic wrote:
Tests that need to actually run generated code go into the test-suite repo. (I
don't think that's really necessary here, though; if you're going to start
https://github.com/efriedma-quic commented:
Please clang-format changes.
https://github.com/llvm/llvm-project/pull/75371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -4315,6 +4453,13 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
return RValue::get(Ptr);
}
+ case Builtin::BI__builtin_clear_padding: {
+const Expr *Op = E->getArg(0);
+Value *Address = EmitScalarExpr(Op);
@@ -2327,6 +2327,25 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl,
unsigned BuiltinID,
}
case Builtin::BI__builtin_launder:
return SemaBuiltinLaunder(*this, TheCall);
+ case Builtin::BI__builtin_clear_padding: {
+const Expr *PtrArg =
@@ -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
@@ -2327,6 +2327,25 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl,
unsigned BuiltinID,
}
case Builtin::BI__builtin_launder:
return SemaBuiltinLaunder(*this, TheCall);
+ case Builtin::BI__builtin_clear_padding: {
+const Expr *PtrArg =
@@ -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
@@ -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
@@ -60,9 +60,14 @@
#include "llvm/Support/ScopedPrinter.h"
#include "llvm/TargetParser/AArch64TargetParser.h"
#include "llvm/TargetParser/X86TargetParser.h"
+#include
#include
#include
+
+
+#include
efriedma-quic wrote:
iostream is forbidden in LLVM
@@ -2327,6 +2327,25 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl,
unsigned BuiltinID,
}
case Builtin::BI__builtin_launder:
return SemaBuiltinLaunder(*this, TheCall);
+ case Builtin::BI__builtin_clear_padding: {
+const Expr *PtrArg =
@@ -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
@@ -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
@@ -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
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/75371
___
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/78637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> ```c
> struct x {
> int a;
> char foo[2][40];
> int b;
> int c;
> };
>
> size_t f(struct x *p, int idx) {
> return __builtin_dynamic_object_size(>foo[idx], 1);
> }
> ```
If I'm following correctly, the return here is 0, 40, or 80, depending on the
@@ -10524,6 +10524,11 @@ Sema::PerformCopyInitialization(const
InitializedEntity ,
Expr *InitE = Init.get();
assert(InitE && "No initialization expression?");
+ if (LangOpts.HLSL)
+if (auto AdjTy = dyn_cast(Entity.getType()))
+ if
@@ -3569,6 +3569,7 @@ bool Expr::HasSideEffects(const ASTContext ,
case ConceptSpecializationExprClass:
case RequiresExprClass:
case SYCLUniqueStableNameExprClass:
+ case HLSLArrayTemporaryExprClass:
efriedma-quic wrote:
This looks wrong; I think you
efriedma-quic wrote:
For the question about querying module flags, we do that in a few different
places in codegen; grep for "getModuleFlag". Not sure if there's anything
specifically in TargetLowering.
https://github.com/llvm/llvm-project/pull/76558
efriedma-quic wrote:
What's the expected interaction here with LTO? Modifying TargetOptions has no
effect if we're generating a bitcode file.
https://github.com/llvm/llvm-project/pull/79256
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/73511
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -21471,6 +21471,53 @@ bool isHalvingTruncateOfLegalScalableType(EVT SrcVT,
EVT DstVT) {
(SrcVT == MVT::nxv2i64 && DstVT == MVT::nxv2i32);
}
+// Combine store (trunc X to <3 x i8>) to sequence of ST1.b.
+static SDValue combineI8TruncStore(StoreSDNode *ST,
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/79298
___
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/79298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> maybe we could add the subtype as part of the llvm.objectsize intrinsic and
> use that instead of grappling with the whole object's type
I'm not sure I follow; if you know the object's type, doesn't that mean you
also know its size?
>(I don't readily know of any
@@ -281,23 +279,19 @@ entry:
define void @store_trunc_add_from_64bits(ptr %src, ptr %dst) {
; CHECK-LABEL: store_trunc_add_from_64bits:
; CHECK: ; %bb.0: ; %entry
-; CHECK-NEXT:sub sp, sp, #16
-; CHECK-NEXT:.cfi_def_cfa_offset 16
; CHECK-NEXT:ldr s0, [x0]
;
@@ -21471,6 +21471,57 @@ bool isHalvingTruncateOfLegalScalableType(EVT SrcVT,
EVT DstVT) {
(SrcVT == MVT::nxv2i64 && DstVT == MVT::nxv2i32);
}
+// Combine store (trunc X to <3 x i8>) to sequence of ST1.b.
+static SDValue combineI8TruncStore(StoreSDNode *ST,
@@ -21248,6 +21248,51 @@ static SDValue foldTruncStoreOfExt(SelectionDAG ,
SDNode *N) {
return SDValue();
}
+// A custom combine to lower load <3 x i8> as the more efficient sequence
+// below:
+//ldrb wX, [x0, #2]
+//ldrh wY, [x0]
+//orr wX, wY, wX, lsl #16
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/78916
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Trying to summarize my understanding here:
- Using the type of an alloca in LLVM IR is wrong, for a variety of reasons.
(At this point, the type of an alloca is basically just leftover junk from
before the opaque pointer transition; I expect that we'll kill it off
@@ -21471,6 +21471,57 @@ bool isHalvingTruncateOfLegalScalableType(EVT SrcVT,
EVT DstVT) {
(SrcVT == MVT::nxv2i64 && DstVT == MVT::nxv2i32);
}
+// Combine store (trunc X to <3 x i8>) to sequence of ST1.b.
+static SDValue combineI8TruncStore(StoreSDNode *ST,
@@ -21471,6 +21471,57 @@ bool isHalvingTruncateOfLegalScalableType(EVT SrcVT,
EVT DstVT) {
(SrcVT == MVT::nxv2i64 && DstVT == MVT::nxv2i32);
}
+// Combine store (trunc X to <3 x i8>) to sequence of ST1.b.
+static SDValue combineI8TruncStore(StoreSDNode *ST,
@@ -281,23 +279,19 @@ entry:
define void @store_trunc_add_from_64bits(ptr %src, ptr %dst) {
; CHECK-LABEL: store_trunc_add_from_64bits:
; CHECK: ; %bb.0: ; %entry
-; CHECK-NEXT:sub sp, sp, #16
-; CHECK-NEXT:.cfi_def_cfa_offset 16
; CHECK-NEXT:ldr s0, [x0]
;
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/79067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
(I'm going to ignore the indentation issues here, and address in a followup.)
https://github.com/llvm/llvm-project/pull/79067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
Putting a function in TargetMachine seems reasonable.
https://github.com/llvm/llvm-project/pull/76558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I can sort of see how a define could be useful, but this doesn't match any
existing usage of __USER_LABEL_PREFIX__ given the relevant rules. I think
reusing the name is more likely to cause confusion, rather than help anyone.
@@ -11,6 +11,7 @@
//===--===//
#include "SystemZ.h"
+#include "clang/AST/Decl.h"
efriedma-quic wrote:
If I recall correctly, in certain build configurations, like if you enable
shared
efriedma-quic wrote:
clang has never emitted diagnostics for failure to inline an always_inline
function. But if gcc is doing it, maybe defaulting to an error isn't such a
big deal.
Separately, it's probably worth ensuring that the LLVM inlining passes don't
actually perform illegal
@@ -2988,7 +2988,10 @@ static Address EmitX86_64VAArgFromMemory(CodeGenFunction
,
// AMD64-ABI 3.5.7p5: Step 10. Align l->overflow_arg_area upwards to
// an 8 byte boundary.
- uint64_t SizeInBytes = (CGF.getContext().getTypeSize(Ty) + 7) / 8;
+ uint64_t SizeInBytes =
efriedma-quic wrote:
There's no general rule that forbids taking the address of an always_inline
function. So if a user really wants to, they can call a mismatched
always_inline function anyway. Given that, making this a hard error seems a
bit dubious; it should probably be a warning
501 - 600 of 882 matches
Mail list logo
