@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
return T->getTypeClass() == ConstantArray ||
T->getTypeClass() == VariableArray ||
T->getTypeClass() == IncompleteArray ||
- T->getTypeClass() == DependentS
https://github.com/efriedma-quic commented:
Oh, this is making a bit more sense now... I didn't realize this was overriding
method that handles char/short already. And I guess for BPF targets, you can
assume "long" is 64 bits.
That said, this isn't handling "unsigned int" correctly. "unsigne
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> My understanding is that you refer to the following part of the
> [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):
Yes. For example, on RISC-V, the function `long f(unsigned g) { return (int)g;
}` compiles to just a "ret".
> clang would
@@ -259,6 +259,10 @@ Bug Fixes in This Version
operator.
Fixes (#GH83267).
+- Clang no longer fails to codegen static ``const`` variables whose
initialiser performs
+ a floating-point division by 0 in C23.
+ Fixes (#GH84784).
efriedma-quic wrote:
We us
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 fi
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; LGTM
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
+const CGRecordLayout &CGRL = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
+const CGRecordLayout &CGRL = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field
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
@@ -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);
+unsig
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
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 lvalue
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
https://lists.llvm.org/cgi-bin/mailman/listin
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 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 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
@@ -662,6 +662,12 @@ def Clz : Builtin, BitShort_Int_Long_LongLongTemplate {
// FIXME: Add int clzimax(uintmax_t)
efriedma-quic wrote:
Probably; it's unlikely we're going to add them at this point.
https://github.com/llvm/llvm-project/pull/83431
_
@@ -2212,6 +2212,54 @@ static bool SemaBuiltinPopcountg(Sema &S, CallExpr
*TheCall) {
return false;
}
+/// Checks that __builtin_{clzg,ctzg} was called with a first argument, which
is
+/// an unsigned integer, and an optional second argument, which is promoted to
+/// an '
@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
if (Result->getType() != ResultType)
efriedma-quic wrote:
Not sure if the way this is handling isCLZForZeroUndef() is what you want?
https://github.com/
@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
if (Result->getType() != ResultType)
efriedma-quic wrote:
I was more thinking of the opposite: we don't need to make the result of the
clz defined if we
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -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
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 mem
@@ -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 &CGM,
@@ -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 &CGM,
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
@@ -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 *Exp
@@ -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 "host-byteorder-little-end
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
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 ot
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 unt
@@ -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, Selection
@@ -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, Selection
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
comple
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
@@ -21248,6 +21248,51 @@ static SDValue foldTruncStoreOfExt(SelectionDAG &DAG,
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
@@ -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, Selection
@@ -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]
;
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 transfo
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
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
@@ -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, Selection
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
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
http
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
__
@@ -3569,6 +3569,7 @@ bool Expr::HasSideEffects(const ASTContext &Ctx,
case ConceptSpecializationExprClass:
case RequiresExprClass:
case SYCLUniqueStableNameExprClass:
+ case HLSLArrayTemporaryExprClass:
efriedma-quic wrote:
This looks wrong; I think yo
@@ -10524,6 +10524,11 @@ Sema::PerformCopyInitialization(const
InitializedEntity &Entity,
Expr *InitE = Init.get();
assert(InitE && "No initialization expression?");
+ if (LangOpts.HLSL)
+if (auto AdjTy = dyn_cast(Entity.getType()))
+ if (AdjTy->getOriginalType(
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(&p->foo[idx], 1);
> }
> ```
If I'm following correctly, the return here is 0, 40, or 80, depending on the
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
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
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -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 = TheCall->getArg(0)->Ig
@@ -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 co
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -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 = TheCall->getArg(0)->Ig
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
@@ -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 = TheCall->getArg(0)->Ig
@@ -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);
---
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
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
@@ -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
@@ -2456,6 +2461,139 @@ static RValue
EmitHipStdParUnsupportedBuiltin(CodeGenFunction *CGF,
return RValue::get(CGF->Builder.CreateCall(UBF, Args));
}
+template
+void RecursivelyClearPaddingImpl(CodeGenFunction &CGF, Value *Ptr, QualType
Ty, size_t CurrentStartOffset, size
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
cfe-c
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
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
@@ -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
@@ -1209,8 +1301,21 @@ static void emitStoresForConstant(CodeGenModule &CGM,
const VarDecl &D,
// If the initializer is all or mostly the same, codegen with bzero / memset
// then do a few stores afterward.
if (shouldUseBZeroPlusStoresToInitialize(constant, ConstantSize)
@@ -1038,11 +1038,14 @@ void CodeGenFunction::EmitNewArrayInitializer(
return true;
};
+ const InitListExpr *ILE = dyn_cast(Init);
+ const CXXParenListInitExpr *CPLIE = dyn_cast(Init);
+ const StringLiteral *SL = dyn_cast(Init);
// If the initializer is an initiali
@@ -1038,11 +1038,14 @@ void CodeGenFunction::EmitNewArrayInitializer(
return true;
};
+ const InitListExpr *ILE = dyn_cast(Init);
+ const CXXParenListInitExpr *CPLIE = dyn_cast(Init);
+ const StringLiteral *SL = dyn_cast(Init);
// If the initializer is an initiali
https://github.com/efriedma-quic approved this pull request.
LGTM
The logic in CGExprCXX.cpp is a bit more complicated than I'd like, but I don't
see any obvious way to simplify it.
https://github.com/llvm/llvm-project/pull/76976
___
cfe-commits mail
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 instead
@@ -2988,7 +2988,10 @@ static Address EmitX86_64VAArgFromMemory(CodeGenFunction
&CGF,
// 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:
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 inlining
@@ -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 libra
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.
https://github.com/llvm/llvm-project/pull/78913
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'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
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
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
@@ -97,14 +97,45 @@ AArch64FunctionInfo::AArch64FunctionInfo(const Function &F,
if (const auto *BTE = mdconst::extract_or_null(
F.getParent()->getModuleFlag("branch-target-enforcement")))
BranchTargetEnforcement = BTE->getZExtValue();
-return;
+ } els
@@ -1757,46 +1826,55 @@ void AArch64FrameLowering::emitPrologue(MachineFunction
&MF,
}
}
- StackOffset AllocateBefore = SVEStackSize, AllocateAfter = {};
+ StackOffset SVECalleeSavedSize = {}, SVELocalsSize = SVEStackSize;
MachineBasicBlock::iterator CalleeSavesBeg
@@ -1757,46 +1826,55 @@ void AArch64FrameLowering::emitPrologue(MachineFunction
&MF,
}
}
- StackOffset AllocateBefore = SVEStackSize, AllocateAfter = {};
+ StackOffset SVECalleeSavedSize = {}, SVELocalsSize = SVEStackSize;
MachineBasicBlock::iterator CalleeSavesBeg
@@ -1076,6 +1076,16 @@ void CodeGenModule::Release() {
"sign-return-address-with-bkey", 1);
}
+ if (Arch == llvm::Triple::aarch64 || Arch == llvm::Triple::aarch64_be) {
+auto *InlineAsm = llvm::MDString::get(TheModule.getContext(),
"inli
efriedma-quic wrote:
I don't think a global variable is the right interface for this; we've been
trying to move away from global variables because they cause breakage when LLVM
is used in multiple contexts in the same process.
Functions that construct pass pipelines that are usable as librarie
Author: efriedma
Date: Wed Aug 2 16:22:50 2017
New Revision: 309901
URL: http://llvm.org/viewvc/llvm-project?rev=309901&view=rev
Log:
[coverage] Make smaller regions for the first case of a switch.
We never overwrite the end location of a region, so we would end up with
an overly large region wh
Author: efriedma
Date: Thu Aug 3 15:27:36 2017
New Revision: 309995
URL: http://llvm.org/viewvc/llvm-project?rev=309995&view=rev
Log:
[coverage] Special-case calls to noreturn functions.
The code after a noreturn call doesn't execute.
The pattern in the testcase is pretty common in LLVM (a swit
Author: efriedma
Date: Tue Aug 8 13:10:14 2017
New Revision: 310406
URL: http://llvm.org/viewvc/llvm-project?rev=310406&view=rev
Log:
[coverage] Special-case calls to noreturn functions.
The code after a noreturn call doesn't execute.
The pattern in the testcase is pretty common in LLVM (a swit
Author: Eli Friedman
Date: 2021-05-17T13:18:23-07:00
New Revision: 698568b74c93ab6d9374adc8bdc6e60fbcf41ff1
URL:
https://github.com/llvm/llvm-project/commit/698568b74c93ab6d9374adc8bdc6e60fbcf41ff1
DIFF:
https://github.com/llvm/llvm-project/commit/698568b74c93ab6d9374adc8bdc6e60fbcf41ff1.diff
Author: Eli Friedman
Date: 2021-05-28T15:36:01-07:00
New Revision: 577fea4e1a13319adf2b660f57bf570195a7f78d
URL:
https://github.com/llvm/llvm-project/commit/577fea4e1a13319adf2b660f57bf570195a7f78d
DIFF:
https://github.com/llvm/llvm-project/commit/577fea4e1a13319adf2b660f57bf570195a7f78d.diff
Author: Eli Friedman
Date: 2021-07-31T13:20:47-07:00
New Revision: 2a2847823f0d13188c43ebdd0baf42a95df750c7
URL:
https://github.com/llvm/llvm-project/commit/2a2847823f0d13188c43ebdd0baf42a95df750c7
DIFF:
https://github.com/llvm/llvm-project/commit/2a2847823f0d13188c43ebdd0baf42a95df750c7.diff
Author: Eli Friedman
Date: 2021-07-31T13:41:15-07:00
New Revision: 6eb2ffbaeb56c8b08ad17c823e1699b964e10b8b
URL:
https://github.com/llvm/llvm-project/commit/6eb2ffbaeb56c8b08ad17c823e1699b964e10b8b
DIFF:
https://github.com/llvm/llvm-project/commit/6eb2ffbaeb56c8b08ad17c823e1699b964e10b8b.diff
Author: Eli Friedman
Date: 2022-10-19T14:40:52-07:00
New Revision: 795f67934d38c2c080aa65f5244dcbdccdbd1154
URL:
https://github.com/llvm/llvm-project/commit/795f67934d38c2c080aa65f5244dcbdccdbd1154
DIFF:
https://github.com/llvm/llvm-project/commit/795f67934d38c2c080aa65f5244dcbdccdbd1154.diff
Author: Zhiyao Ma
Date: 2022-10-24T11:41:24-07:00
New Revision: 7e8af2fc0c068de8bb47d8046b8483234fab3b13
URL:
https://github.com/llvm/llvm-project/commit/7e8af2fc0c068de8bb47d8046b8483234fab3b13
DIFF:
https://github.com/llvm/llvm-project/commit/7e8af2fc0c068de8bb47d8046b8483234fab3b13.diff
LOG
Author: Eli Friedman
Date: 2022-10-11T14:00:33-07:00
New Revision: 1079662d2fff7ae799503d910b299c5108d105fd
URL:
https://github.com/llvm/llvm-project/commit/1079662d2fff7ae799503d910b299c5108d105fd
DIFF:
https://github.com/llvm/llvm-project/commit/1079662d2fff7ae799503d910b299c5108d105fd.diff
301 - 400 of 1669 matches
Mail list logo
