efriedma-quic wrote:
I don't like the "ExprLValueMap" approach for array bounds checking; it's
fragile and doesn't handle cases we should be able to handle. In particular,
we should be able to handle arbitrary base expressions for array bounds
checking, I think; there should be a constant
efriedma-quic wrote:
I'm a little surprised we don't need any LLVM backend changes, but I guess in
soft-float mode we basically treat floats as ints anyway, so maybe things just
work. I'd like to see appropriate regression tests, though (if they don't
already exist).
efriedma-quic wrote:
The C notion of "compatibility" with regard to enums is a bit weird... clang
and gcc disagree whether `enum e : int; enum e2: int; enum e x; int x; enum e2
x;` is valid because 6.2.7 doesn't actually define what's supposed to happen.
Probably this should be illegal, but
https://github.com/efriedma-quic approved this pull request.
LGTM
In terms of va_list etc., we first need to make sure calls are correct (compare
against gcc etc.), then we need to make sure va_list is consistent with that.
https://github.com/llvm/llvm-project/pull/72197
efriedma-quic wrote:
My primary concerns here are:
- It being likely these builtins will be superseded by something else once
someone else tries to standardize this. Maybe this isn't a big deal... but
maybe we want to choose names that are less likely to overlap with stuff anyone
else is
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I agree users probably shouldn't be doing that... but given it compiles your
code should handle it gracefully. (It should just be a matter of making sure
you don't recurse too deeply through the "base".)
https://github.com/llvm/llvm-project/pull/73730
@@ -418,14 +418,20 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfo(QualType QTy) {
return nullptr;
const Type *Ty = Context.getCanonicalType(QTy).getTypePtr();
- if (llvm::MDNode *N = BaseTypeMetadataCache[Ty])
-return N;
- // Note that the following helper call
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/73264
___
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/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic approved this pull request.
LGTM
See
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
for the rules on use/don't use braces. A single multi-line statement is sort
of on the edge; I tend
efriedma-quic wrote:
As a historical note, when I first wrote the support for atomics, it was under
a model where LLVM IR only modeled legal atomics, and clang lowered illegal
atomics to libcalls. This was changed a few years later to generalize atomics
in LLVM IR to support arbitrary atomic
efriedma-quic wrote:
The concept makes sense, but I think the code should be inside
CodeGenModule::GetAddrOfTemplateParamObject? I think all users of the function
want a value in the correct address-space.
https://github.com/llvm/llvm-project/pull/69266
efriedma-quic wrote:
Some examples to consider:
```
// Crazy array indexing... but strictly speaking, legal.
struct S { int count; int arr[] __attribute((counted_by(count))); };
int f1(int c, struct S *var) {
return var[10].arr[10];
}
// Double dereferenced variable.
int f2(int c, struct S
efriedma-quic wrote:
I'd like to see a few tests involving multiple arrows in the same expression.
(If my understanding is correct, you want to cut the recursion when you see an
arrow member.)
Looking at the code again, I guess FindCountedByField doesn't explicitly
compute the base
efriedma-quic wrote:
CodeGenFunction::FindCountedByField finds a field with a corresponding base
expression. Currently, it throws away the base expression. And the code
you've just written tries to recompute the base. Instead of doing this dance,
can we just make
@@ -1687,7 +1687,8 @@ CharUnits ASTContext::getDeclAlign(const Decl *D, bool
ForAlignof) const {
if (VD->hasGlobalStorage() && !ForAlignof) {
uint64_t TypeSize =
!BaseT->isIncompleteType() ? getTypeSize(T.getTypePtr()) : 0;
-Align =
efriedma-quic wrote:
Please fix the pull request description to say this is aarch64-specific.
Missing regression test in clang/test/CodeGen/
How does this interact with #72197?
https://github.com/llvm/llvm-project/pull/72624
___
cfe-commits mailing
@@ -0,0 +1,32 @@
+// RUN: %clang --target=s390x-linux -S -emit-llvm -o - %s | FileCheck %s
efriedma-quic wrote:
Sorry, I missed this when reviewing.
We generally only use Driver tests when we're trying to test some aspect of the
driver. For arm-alignment.c,
efriedma-quic wrote:
Missing change to clang/docs/LanguageExtensions.rst describing the new builtins.
Are there any other projects that we might want to coordinate with here? gcc,
maybe?
https://github.com/llvm/llvm-project/pull/72280
___
@@ -0,0 +1,363 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs | FileCheck %s
+
+; Dynamically-sized allocation, needs a loop which can handle any size at
+; runtime. The final
@@ -1076,6 +1076,16 @@ void CodeGenModule::Release() {
"sign-return-address-with-bkey", 1);
}
+ if (Arch == llvm::Triple::aarch64 || Arch == llvm::Triple::aarch64_be) {
efriedma-quic wrote:
Module-level attributes tend to
@@ -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(),
@@ -0,0 +1,722 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs | FileCheck %s
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs -global-isel
-global-isel-abort=2 |
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/71677
___
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/72197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -307,7 +307,12 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
// 0.
if (IsEmpty && Size == 0)
return ABIArgInfo::getIgnore();
-return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));
+// An empty struct can have
@@ -1627,28 +1627,20 @@ const llvm::fltSemantics
::getFloatTypeSemantics(QualType T) const {
CharUnits ASTContext::getDeclAlign(const Decl *D, bool ForAlignof) const {
unsigned Align = Target->getCharWidth();
- bool UseAlignAttrOnly = false;
- if (unsigned AlignFromAttr
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/72452
___
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/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
@DanielKristofKiss From your response, I gather you want AArch64 to align with
the other targets, but additional changes are required to make that work?
In the interest of keeping things moving, how do you want to stage this? Would
it make sense to land this as-is? Rhen
efriedma-quic wrote:
I'll try describing it a different way.
There are two kinds of alignment. "ABI alignment" is required for the code to
function correctly (due to things like architecture constraints, reusing the
low bit for member pointers, binary patching). "Preferred alignment" is
@@ -307,7 +307,13 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
// 0.
if (IsEmpty && Size == 0)
return ABIArgInfo::getIgnore();
-return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));
+// An empty struct can have
https://github.com/efriedma-quic commented:
Good to see this works without any unexpected side-effects.
Please also add a test for 32-byte alignment (since that generates different
code)
https://github.com/llvm/llvm-project/pull/72197
___
https://github.com/efriedma-quic edited
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
efriedma-quic wrote:
Okay. Please add a comment to the code briefly explaining that.
Otherwise looks fine.
https://github.com/llvm/llvm-project/pull/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
We're already assigning names to the different scopes; we're just doing it in
the __MEMORY_SCOPE_* preprocessor macros. Replacing `_MEMORY_SCOPE_SYSTEM` in
the code with `"system"` doesn't really change the nature of how we assign
names to scopes.
If these are supposed
efriedma-quic wrote:
> Is clang aware of the target's default function alignment?
No? On x86, the "default" is set by the line
`setPrefFunctionAlignment(Align(16));`. Which, as the name suggests, is
supposed to be a preference, not a mandatory minimum. And it's subject to
change in the
https://github.com/efriedma-quic approved this pull request.
LGTM
The questions that I came up with while reviewing:
- Does this affect other targets?
It looks like it affects Lanai, but that difference seems fine. It looks like
it doesn't affect anything else in-tree; in particular, the
efriedma-quic wrote:
I mean, looking at the code, as far as I can tell, we always call GetAddrOfVTT
immediately before EmitVTTDefinition, so setGVProperties() has already run, so
running it again shouldn't do anything... unless somehow EmitVTTDefinition is
overwriting the visibility, or
efriedma-quic wrote:
> The underlying implementation is a string literal in the LLVM syncscope
> argument, but the problem is that this isn't standardized at all and varies
> between backends potentially
We don't have to use the same set of strings as syncscope if that doesn't make
sense.
efriedma-quic wrote:
See also #71986
https://github.com/llvm/llvm-project/pull/72298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Can you not test this by checking an `__attribute__((swiftcall))` function
works in C?
https://github.com/llvm/llvm-project/pull/72298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
> I figured we can just treat these as clang extensions for the time being. We
> already have two variants that are more or less redundant for specific
> use-cases, (OpenCL and HIP), which should be able to be removed after this.
I'm not sure what you mean here. If you
efriedma-quic wrote:
I'm a little wary of adding these without actually going through any sort of
standardization process; if other vendors don't support the same interface, we
just have more variations. (See also
https://clang.llvm.org/get_involved.html#criteria )
How consistent are the
@@ -232,19 +232,19 @@ static Value *MakeBinaryAtomicValue(
static Value *EmitNontemporalStore(CodeGenFunction , const CallExpr *E) {
Value *Val = CGF.EmitScalarExpr(E->getArg(0));
- Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+ Address Addr =
@@ -395,27 +395,27 @@ namespace {
void CodeGenFunction::EmitAnyExprToExn(const Expr *e, Address addr) {
// Make sure the exception object is cleaned up if there's an
// exception during initialization.
- pushFullExprCleanup(EHCleanup, addr.getPointer());
-
@@ -80,6 +94,139 @@ class Address {
return Alignment;
}
+ /// Return address with different element type, but same pointer and
+ /// alignment.
+ RawAddress withElementType(llvm::Type *ElemTy) const {
+return RawAddress(getPointer(), ElemTy, getAlignment(),
efriedma-quic wrote:
I'd prefer not to call setGVProperties() twice on the same variable; under what
conditions is the first call not sufficient?
https://github.com/llvm/llvm-project/pull/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
The proper fix here is probably to just delete the `return
ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));` from the empty
struct codepath on aarch64.
Alignment shouldn't affect whether a class is empty. The issue here is just
that according to aarch64
efriedma-quic wrote:
This patch appears to do two things:
- Add a "default align" attribute, which instructions the backend to use some
unspecified "default" alignment for the function in question.
- Tells the frontend to apply this attribute specifically to "cold" functions.
This is
efriedma-quic wrote:
Looks fine now. (You might want to change the title before merging.)
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
The simplest thing to do is rebase and force-push. You can alternatively try
to use a merge commit, but I'm not completely sure how github would react to
that.
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits
https://github.com/efriedma-quic approved this pull request.
I see unrelated changes on the branch? Otherwise LGTM
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
}
llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/71452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1506,8 +1497,16 @@ TEST_CUSTOM(unmatchedreverse, unmatchedreverse, { .c =
42 });
// CHECK-O0:call void @llvm.memcpy
// CHECK-NOT: !annotation
// CHECK-O0:call void @{{.*}}used{{.*}}%custom)
-// PATTERN-O1: store i32 -1431655894, ptr {{.*}}, align 4
-//
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule ,
const VarDecl ,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case when
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule ,
const VarDecl ,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case when
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule ,
const VarDecl ,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case when
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite
efriedma-quic wrote:
> That seems reasonable, however, there are other QOI reasons for attempting to
> generate globally unique names for lambdas
Sure. But we wouldn't want to special-case vftables for that.
> I think our strategy to ensure internal lambdas like this are globally unique
>
efriedma-quic wrote:
> Why are we creating a comdat here in the first place?
I guess that's b2615aa4... but I'm pretty sure we fixed -fdata-sections so the
backend automatically generates comdats. So maybe we should just revert that.
> If we allow creating a comdat associated with an
efriedma-quic wrote:
Why are we creating a comdat here in the first place? Creating a comdat
associated with an internal symbol doesn't do anything useful: an internal
symbol can't be defined in any other translation unit, so the comdat will never
be discarded.
If we allow creating a comdat
@@ -359,6 +359,13 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public
TargetInfo {
bool isSPRegName(StringRef RegName) const override {
return RegName.equals("r1") || RegName.equals("x1");
}
+
+ // We support __builtin_cpu_supports/__builtin_cpu_is on targets
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite
efriedma-quic wrote:
The C equivalent to the C++11 rule is in 6.8.5, which says "An iteration
statement may be assumed by the implementation to terminate if [...]". There's
no general rule that a program has to make progress if there isn't a loop
involved.
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
}
llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
https://github.com/efriedma-quic commented:
Added reviewers from https://reviews.llvm.org/D127812, for the AArch64 side.
https://github.com/llvm/llvm-project/pull/71706
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/71706
___
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/70171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1741,6 +1742,69 @@ void AArch64DAGToDAGISel::SelectCVTIntrinsic(SDNode *N,
unsigned NumVecs,
CurDAG->RemoveDeadNode(N);
}
+void AArch64DAGToDAGISel::SelectSMELdrStrZA(SDNode *N, bool IsLoad) {
+ // Lower an SME LDR/STR ZA intrinsic to LDR_ZA_PSEUDO or STR_ZA.
+ // If
@@ -976,6 +976,37 @@ void CodeGenModule::Release() {
Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+ if (getTriple().isOSzOS()) {
+
@@ -976,6 +976,37 @@ void CodeGenModule::Release() {
Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+ if (getTriple().isOSzOS()) {
+
efriedma-quic wrote:
It should be possible to statically link a pass plugin without modifying any
LLVM/clang build files. polly uses this infrastructure. (polly is actually
referenced explicitly in a couple places, but only to pull it into the build in
the first place; you can do something
efriedma-quic wrote:
Do you need to check if the lambda is templated? For example, the following
doesn't compile:
```
auto GetNonCapturingLambda() { return [](){ return 42; }; }
auto f() { return GetNonCapturingLambda() == GetNonCapturingLambda(); }
```
efriedma-quic wrote:
(Not sure if you have commit access; let me know if you want me to merge for
you.)
https://github.com/llvm/llvm-project/pull/66716
___
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/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
The new option in CodeGenOptions.h seems fine.
If your goal is to statically inject passes into the clang executable, I don't
understand why the existing LLVM plugin infrastructure isn't sufficient for
your needs. You mention "modifying Extension.def", but that file is
@@ -622,6 +622,28 @@ static bool checkAliasedGlobal(
return true;
}
+// Emit a warning if toc-data attribute is requested for global variables that
+// have aliases and remove the toc-data attribute.
+static void checkAliasForTocData(llvm::GlobalVariable *GVar,
+
https://github.com/efriedma-quic commented:
What are the ABI implications here? Do all translation units have to agree on
whether a variable is "tocdata"? The manual change hints there's some sort of
linker fixup, but it's not clear to me how that works.
Specifying the names of global
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/67999
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -265,6 +269,63 @@ bool AIXTargetCodeGenInfo::initDwarfEHRegSizeTable(
return PPC_initDwarfEHRegSizeTable(CGF, Address, Is64Bit, /*IsAIX*/ true);
}
+void AIXTargetCodeGenInfo::setTargetAttributes(
+const Decl *D, llvm::GlobalValue *GV, CodeGen::CodeGenModule ) const {
efriedma-quic wrote:
Is there some reason stack protectors don't make sense on GPU targets? Or is
the issue just that the GPU targets in question don't have the necessary
runtime support?
https://github.com/llvm/llvm-project/pull/70799
___
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/68565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1741,6 +1742,69 @@ void AArch64DAGToDAGISel::SelectCVTIntrinsic(SDNode *N,
unsigned NumVecs,
CurDAG->RemoveDeadNode(N);
}
+void AArch64DAGToDAGISel::SelectSMELdrStrZA(SDNode *N, bool IsLoad) {
+ // Lower an SME LDR/STR ZA intrinsic to LDR_ZA_PSEUDO or STR_ZA.
+ // If
https://github.com/efriedma-quic commented:
The resulting code here still isn't great quality for the case where the
constant isn't folded. Maybe worth considering doing the lowering earlier
(DAGCombine? Maybe even a late IR optimization?), so the lowered arithmetic
can be optimized.
efriedma-quic wrote:
I'm planning to take a closer look at this when I have more time. Sorry I
haven't been more responsive here.
One very brief note: in the comments in the code, you might want to distinguish
between the semantic width of a bitfield (i.e. the C standard notion of a
"memory
efriedma-quic wrote:
Also, you might want to consider marking the offset immarg, instead of trying
to handle variable offsets in isel.
https://github.com/llvm/llvm-project/pull/68565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic commented:
Could you briefly comment on the tradeoff of adding an argument to the
intrinsic, vs. pattern-matching constant offsets to the existing intrinsic?
https://github.com/llvm/llvm-project/pull/68565
___
@@ -292,7 +292,42 @@ define void @ldr_with_off_16mulvl(ptr %ptr) {
%vscale = call i64 @llvm.vscale.i64()
%mulvl = mul i64 %vscale, 256
%base = getelementptr i8, ptr %ptr, i64 %mulvl
- call void @llvm.aarch64.sme.ldr(i32 16, ptr %base)
+ call void
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/68565
___
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/70366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I think I'd prefer to avoid calling into ConstExprEmitter at all for cases
involving reference binding. I think we've sort of discussed this before.
Maybe add a check to tryEmitPrivate()? (We already have a check in
tryEmitPrivateForVarInit().)
801 - 900 of 1033 matches
Mail list logo
