[llvm-branch-commits] [llvm] CodeGen: Remove UsesMSVCFloatingPoint from MachineModuleInfo (PR #100368)
jyknight wrote: It's been a while since I looked at this, but its purpose, at least back then (2c36240a820c27450c0626a7161646e2d20d3f6d) is very different than what was discussed above. It had two effects: 1. decide whether to include floating-point support in printf/scanf library routines. 2. decide whether to include code to modify the x87 FPU mode flags at program startup to the expected values. https://github.com/llvm/llvm-project/pull/100368 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] CodeGen: Remove UsesMSVCFloatingPoint from MachineModuleInfo (PR #100368)
jyknight wrote: In particular, I think it would be incorrect to just look at floating-point operations at the MIR level, because calling printf with a constant floating point argument doesn't necessarily use any floating point instructions. https://github.com/llvm/llvm-project/pull/100368 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)
jyknight wrote: Why not condition this on `-no-pic`, and keep the previous more-optimal layout for the normal case? https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)
jyknight wrote: ISTM that making the layout conditional in order to not regress the most-common case (PIE) would be worth a minor amount of code in lld, even though the benefit is also relatively small. Do you think INSERT scripts are going to be a real-world issue there? It seems to me like it wouldn't much matter to someone doing INSERT BEFORE/AFTER .lrodata, if lrodata goes near the beginning or near the end? https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)
jyknight wrote: I don't follow. no-pie is _uncommon_ but not _unsupported_. Making users add a linker script when they wouldn't otherwise have one, in order to have a working no-pie build seems unjustified. https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)
jyknight wrote: > I don't think this means that we unsupport -no-pie use cases Yes, we'd still support -no-pie, but we'd fail to support -no-pie -mcmodel=medium. > cost of layout purity I see that you feel strongly about this (e.g. by calling it "purity"), but I don't understand why. It's not the cost of the "if" in the implementation you're worried about, I think, but some other aspect? > INSERT AFTER .lrodata would give different behaviors (a 32-bit offset > relative to .text is positive in one while negative in the other) I agree that the sign of the relative offset will change...but why is that concerning? The whole point of "INSERT AFTER" is to avoid specifying the entire layout. Does it matter that the offset relative to .text is sometimes negative and sometimes positive? > which we should not treat hand-wavy. Have scripts been broken by the _unconditional_ change from the offset being always-negative to the offset being always-positive? It seems unlikely to me that they would be, but am I missing something? If they don't, then that seems like having it be conditional is also fine. https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Sparc] limit MaxAtomicSizeInBitsSupported to 32 for 32-bit Sparc. (#81655) (PR #81713)
jyknight wrote: Do we need this backported, given that the triggering commit isn't going to be backported? https://github.com/llvm/llvm-project/pull/81713 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Support placing .lbss/.lrodata/.ldata after .bss (PR #81224)
@@ -1436,6 +1436,8 @@ static void readConfigs(opt::InputArgList &args) {
config->zInterpose = hasZOption(args, "interpose");
config->zKeepTextSectionPrefix = getZFlag(
args, "keep-text-section-prefix", "nokeep-text-section-prefix", false);
+ config->zLrodataAfterBss =
+ getZFlag(args, "lrodata-after-bss", "nolrodata-after-bss", false);
jyknight wrote:
Use `!config->isPic` as default value, instead of false? (moving below the
assignment of `isPic`, of course)
https://github.com/llvm/llvm-project/pull/81224
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [ELF] Support placing .lbss/.lrodata/.ldata after .bss (PR #81224)
@@ -1436,6 +1436,8 @@ static void readConfigs(opt::InputArgList &args) {
config->zInterpose = hasZOption(args, "interpose");
config->zKeepTextSectionPrefix = getZFlag(
args, "keep-text-section-prefix", "nokeep-text-section-prefix", false);
+ config->zLrodataAfterBss =
+ getZFlag(args, "lrodata-after-bss", "nolrodata-after-bss", false);
jyknight wrote:
OK...then it ought to default to true, instead of false.
(And I do also wish you would explain better why you feel so strongly about not
changing behavior based on pic vs not.)
https://github.com/llvm/llvm-project/pull/81224
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [cmake] Add minor version to library SONAME (#79376) (PR #82409)
jyknight wrote: So the problem Rust sees isn't that a ".1" was added to the version, but rather that the name was changed from "libLLVM-18-rust-1.78.0-nightly.so" to "libLLVM.so.18.1-rust-1.78.0-nightly". (that is: all the version info previously went into the library name which comes before ".so", and now goes into the library version which comes after ".so"). And issues with symlinks on Windows. https://github.com/llvm/llvm-project/pull/82409 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [X86] Avoid generating nested CALLSEQ for TLS pointer function arguments (PR #106965)
jyknight wrote: This sounds sketchy to me. Is it really valid to enter a second call inside another call's CALLSEQ markers, but only if we avoid adding a second nested set of markers? It feels like attacking the symptom of the issue, but not the root cause. (I'm not certain it's _not_ valid, but it just seems really suspicious...) https://github.com/llvm/llvm-project/pull/106965 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxxabi] b0085d2 - Itanium Mangling: Mangle `__alignof__` differently than `alignof`.
Author: James Y Knight
Date: 2021-01-27T20:02:29-05:00
New Revision: b0085d205b3063c332a080599830ef0500cb6924
URL:
https://github.com/llvm/llvm-project/commit/b0085d205b3063c332a080599830ef0500cb6924
DIFF:
https://github.com/llvm/llvm-project/commit/b0085d205b3063c332a080599830ef0500cb6924.diff
LOG: Itanium Mangling: Mangle `__alignof__` differently than `alignof`.
The two operations have acted differently since Clang 8, but were
unfortunately mangled the same. The new mangling uses new "vendor
extended expression" syntax proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112
GCC had the same mangling problem, https://gcc.gnu.org/PR88115, and
will hopefully be switching to the same mangling as implemented here.
Additionally, fix the mangling of `__uuidof` to use the new extension
syntax, instead of its previous nonstandard special-case.
Adjusts the demangler accordingly.
Differential Revision: https://reviews.llvm.org/D93922
(cherry picked from commit 9c7aeaebb3ac1b94200b59b111742cb6b8f090c2)
Added:
clang/test/CodeGenCXX/mangle-alignof.cpp
Modified:
clang/lib/AST/ItaniumMangle.cpp
clang/test/CodeGenCXX/microsoft-uuidof-mangling.cpp
libcxxabi/src/demangle/ItaniumDemangle.h
libcxxabi/test/test_demangle.pass.cpp
llvm/include/llvm/Demangle/ItaniumDemangle.h
Removed:
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 6c8d5687c64a..668733a4be34 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -558,6 +558,7 @@ class CXXNameMangler {
unsigned NumTemplateArgs);
void mangleTemplateArgs(TemplateName TN, const TemplateArgumentList &AL);
void mangleTemplateArg(TemplateArgument A, bool NeedExactType);
+ void mangleTemplateArgExpr(const Expr *E);
void mangleValueInTemplateArg(QualType T, const APValue &V, bool TopLevel,
bool NeedExactType = false);
@@ -3528,8 +3529,8 @@ void CXXNameMangler::mangleType(const
DependentSizedMatrixType *T) {
Out << "u" << VendorQualifier.size() << VendorQualifier;
Out << "I";
- mangleTemplateArg(T->getRowExpr(), false);
- mangleTemplateArg(T->getColumnExpr(), false);
+ mangleTemplateArgExpr(T->getRowExpr());
+ mangleTemplateArgExpr(T->getColumnExpr());
mangleType(T->getElementType());
Out << "E";
}
@@ -3916,6 +3917,7 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity) {
// ::= ds #
expr.*expr
// ::= sZ # size of
a parameter pack
// ::= sZ # size of a function parameter
pack
+ // ::= u * E # vendor extended
expression
// ::=
// ::= L E# integer literal
//::= L E # floating literal
@@ -4007,14 +4009,26 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity) {
case Expr::CXXUuidofExprClass: {
const CXXUuidofExpr *UE = cast(E);
-if (UE->isTypeOperand()) {
- QualType UuidT = UE->getTypeOperand(Context.getASTContext());
- Out << "u8__uuidoft";
- mangleType(UuidT);
+// As of clang 12, uuidof uses the vendor extended expression
+// mangling. Previously, it used a special-cased nonstandard extension.
+if (Context.getASTContext().getLangOpts().getClangABICompat() >
+LangOptions::ClangABI::Ver11) {
+ Out << "u8__uuidof";
+ if (UE->isTypeOperand())
+mangleType(UE->getTypeOperand(Context.getASTContext()));
+ else
+mangleTemplateArgExpr(UE->getExprOperand());
+ Out << 'E';
} else {
- Expr *UuidExp = UE->getExprOperand();
- Out << "u8__uuidofz";
- mangleExpression(UuidExp, Arity);
+ if (UE->isTypeOperand()) {
+QualType UuidT = UE->getTypeOperand(Context.getASTContext());
+Out << "u8__uuidoft";
+mangleType(UuidT);
+ } else {
+Expr *UuidExp = UE->getExprOperand();
+Out << "u8__uuidofz";
+mangleExpression(UuidExp, Arity);
+ }
}
break;
}
@@ -4312,13 +4326,39 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity) {
break;
}
+auto MangleAlignofSizeofArg = [&] {
+ if (SAE->isArgumentType()) {
+Out << 't';
+mangleType(SAE->getArgumentType());
+ } else {
+Out << 'z';
+mangleExpression(SAE->getArgumentExpr());
+ }
+};
+
switch(SAE->getKind()) {
case UETT_SizeOf:
Out << 's';
+ MangleAlignofSizeofArg();
break;
case UETT_PreferredAlignOf:
+ // As of clang 12, we mangle __alignof__
diff erently than alignof. (They
+ // have acted
diff erently since Clang 8, but were previously mangled the
+ // same.)
+ if (Context.getASTContext().getLangOpts().getClangABICompat() >
+ LangOptions::ClangABI::
[llvm-branch-commits] [clang] 7da92af - Itanium Mangling: Fix handling of in .
Author: James Y Knight
Date: 2021-01-27T20:02:30-05:00
New Revision: 7da92afbf08e90960f7e5dee00bbf6ef8f323a5c
URL:
https://github.com/llvm/llvm-project/commit/7da92afbf08e90960f7e5dee00bbf6ef8f323a5c
DIFF:
https://github.com/llvm/llvm-project/commit/7da92afbf08e90960f7e5dee00bbf6ef8f323a5c.diff
LOG: Itanium Mangling: Fix handling of in .
Previously, we were emitting an extraneous X .. E in
around an if the template argument was constructed from
an expression (rather than an already-evaluated literal value). In
such a case, we would then e.g. emit 'XLi0EE' instead of 'Li0E'.
We had one special-case for DeclRefExpr expressions, in particular, to
omit them the mangled-name without the surrounding X/E. However,
unfortunately, that special case also triggered for ParmVarDecl (a
subtype of VarDecl), and _incorrectly_ emitted 'L_Z .. E' instead of
the proper 'Xfp_E'.
This change causes mangleExpression itself to be responsible for
emitting X/E around non-primary expressions, which removes the
special-case, and corrects both these problems.
Differential Revision: https://reviews.llvm.org/D95487
(cherry picked from commit 8ca33605ff0cfc536f5c6710fb5f6378bf11959a)
Added:
Modified:
clang/lib/AST/ItaniumMangle.cpp
clang/test/CodeGenCXX/clang-abi-compat.cpp
clang/test/CodeGenCXX/mangle-abi-tag.cpp
clang/test/CodeGenCXX/mangle-concept.cpp
clang/test/CodeGenCXX/mangle-template.cpp
clang/test/CodeGenCXX/mangle.cpp
clang/test/CodeGenCXX/matrix-type.cpp
clang/test/CodeGenCXX/microsoft-uuidof-mangling.cpp
Removed:
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 668733a4be34..54e2f361a9f1 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -546,8 +546,8 @@ class CXXNameMangler {
unsigned knownArity);
void mangleCastExpression(const Expr *E, StringRef CastEncoding);
void mangleInitListElements(const InitListExpr *InitList);
- void mangleDeclRefExpr(const NamedDecl *D);
- void mangleExpression(const Expr *E, unsigned Arity = UnknownArity);
+ void mangleExpression(const Expr *E, unsigned Arity = UnknownArity,
+bool AsTemplateArg = false);
void mangleCXXCtorType(CXXCtorType T, const CXXRecordDecl *InheritedFrom);
void mangleCXXDtorType(CXXDtorType T);
@@ -3872,33 +3872,8 @@ void CXXNameMangler::mangleInitListElements(const
InitListExpr *InitList) {
mangleExpression(InitList->getInit(i));
}
-void CXXNameMangler::mangleDeclRefExpr(const NamedDecl *D) {
- switch (D->getKind()) {
- default:
-// ::= L E # external name
-Out << 'L';
-mangle(D);
-Out << 'E';
-break;
-
- case Decl::ParmVar:
-mangleFunctionParam(cast(D));
-break;
-
- case Decl::EnumConstant: {
-const EnumConstantDecl *ED = cast(D);
-mangleIntegerLiteral(ED->getType(), ED->getInitVal());
-break;
- }
-
- case Decl::NonTypeTemplateParm:
-const NonTypeTemplateParmDecl *PD = cast(D);
-mangleTemplateParameter(PD->getDepth(), PD->getIndex());
-break;
- }
-}
-
-void CXXNameMangler::mangleExpression(const Expr *E, unsigned Arity) {
+void CXXNameMangler::mangleExpression(const Expr *E, unsigned Arity,
+ bool AsTemplateArg) {
// ::=
// ::=
// ::=
@@ -3912,6 +3887,7 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity) {
// ::= at # alignof (a type)
// ::=
// ::=
+ // ::= fpT# 'this' expression (part
of )
// ::= sr #
dependent name
// ::= sr #
dependent template-id
// ::= ds #
expr.*expr
@@ -3920,11 +3896,55 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity) {
// ::= u * E # vendor extended
expression
// ::=
// ::= L E# integer literal
- //::= L E # floating literal
+ //::= L E # floating literal
+ //::= L E # string literal
+ //::= L E # nullptr literal "LDnE"
+ //::= L 0 E # null pointer template
argument
+ //::= L _ E#
complex floating point literal (C99); not used by clang
//::= L E # external name
- //::= fpT # 'this' expression
QualType ImplicitlyConvertedToType;
+ // A top-level expression that's not needs to be wrapped in
+ // X...E in a template arg.
+ bool IsPrimaryExpr = true;
+ auto NotPrimaryExpr = [&] {
+if (AsTemplateArg && IsPrimaryExpr)
+ Out << 'X';
+IsPrimaryExpr = false;
+ };
+
+ auto MangleDeclRefExpr
[llvm-branch-commits] [clang] 0b7b698 - Itanium Mangling: In 'enable_if', omit X/E around .
Author: James Y Knight
Date: 2021-01-27T20:02:30-05:00
New Revision: 0b7b698fecd37415a635a586e5ca159ab0b8872f
URL:
https://github.com/llvm/llvm-project/commit/0b7b698fecd37415a635a586e5ca159ab0b8872f
DIFF:
https://github.com/llvm/llvm-project/commit/0b7b698fecd37415a635a586e5ca159ab0b8872f.diff
LOG: Itanium Mangling: In 'enable_if', omit X/E around .
The Clang enable_if extension is mangled as an ,
which is supposed to contain . However, we were
unconditionally emitting X/E around its arguments, neglecting the fact
that should be emitted directly without the surrounding
X/E.
Differential Revision: https://reviews.llvm.org/D95488
(cherry picked from commit a7246ba02a8923f316419a62d836dbe1c0b437bd)
Added:
Modified:
clang/lib/AST/ItaniumMangle.cpp
clang/test/CodeGen/enable_if.c
clang/test/CodeGenCXX/clang-abi-compat.cpp
clang/test/CodeGenCXX/enable_if.cpp
Removed:
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 54e2f361a9f1..4420f6a2c1c3 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -727,9 +727,17 @@ void CXXNameMangler::mangleFunctionEncodingBareType(const
FunctionDecl *FD) {
EnableIfAttr *EIA = dyn_cast(*I);
if (!EIA)
continue;
- Out << 'X';
- mangleExpression(EIA->getCond());
- Out << 'E';
+ if (Context.getASTContext().getLangOpts().getClangABICompat() >
+ LangOptions::ClangABI::Ver11) {
+mangleTemplateArgExpr(EIA->getCond());
+ } else {
+// Prior to Clang 12, we hardcoded the X/E around enable-if's argument,
+// even though should not include an X/E around
+// .
+Out << 'X';
+mangleExpression(EIA->getCond());
+Out << 'E';
+ }
}
Out << 'E';
FunctionTypeDepth.pop(Saved);
diff --git a/clang/test/CodeGen/enable_if.c b/clang/test/CodeGen/enable_if.c
index 14550b9e2db9..327a201cdeba 100644
--- a/clang/test/CodeGen/enable_if.c
+++ b/clang/test/CodeGen/enable_if.c
@@ -31,22 +31,22 @@ void bar(int m) __attribute__((overloadable, enable_if(m >
0, "")));
void bar(int m) __attribute__((overloadable, enable_if(1, "")));
// CHECK-LABEL: define{{.*}} void @test2
void test2() {
- // CHECK: store void (i32)* @_Z3barUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3barUa9enable_ifILi1EEi
void (*p)(int) = bar;
- // CHECK: store void (i32)* @_Z3barUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3barUa9enable_ifILi1EEi
void (*p2)(int) = &bar;
- // CHECK: store void (i32)* @_Z3barUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3barUa9enable_ifILi1EEi
p = bar;
- // CHECK: store void (i32)* @_Z3barUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3barUa9enable_ifILi1EEi
p = &bar;
- // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifIXLi1EEEi to i8*)
+ // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifILi1EEi to i8*)
void *vp1 = (void*)&bar;
- // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifIXLi1EEEi to i8*)
+ // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifILi1EEi to i8*)
void *vp2 = (void*)bar;
- // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifIXLi1EEEi to i8*)
+ // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifILi1EEi to i8*)
vp1 = (void*)&bar;
- // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifIXLi1EEEi to i8*)
+ // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifILi1EEi to i8*)
vp1 = (void*)bar;
}
@@ -54,13 +54,13 @@ void baz(int m) __attribute__((overloadable, enable_if(1,
"")));
void baz(int m) __attribute__((overloadable));
// CHECK-LABEL: define{{.*}} void @test3
void test3() {
- // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3bazUa9enable_ifILi1EEi
void (*p)(int) = baz;
- // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3bazUa9enable_ifILi1EEi
void (*p2)(int) = &baz;
- // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3bazUa9enable_ifILi1EEi
p = baz;
- // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+ // CHECK: store void (i32)* @_Z3bazUa9enable_ifILi1EEi
p = &baz;
}
@@ -71,13 +71,13 @@ void qux(int m) __attribute__((overloadable, enable_if(1,
""),
void qux(int m) __attribute__((overloadable, enable_if(1, "")));
// CHECK-LABEL: define{{.*}} void @test4
void test4() {
- // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXLi1EEEi
+ // CHECK: store void (i32)* @_Z3quxUa9enable_ifILi1ELi1EEi
void (*p)(int) = qux;
- // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXLi1EEEi
+ // CHECK: store void (i32)* @_Z3quxUa9enable_ifILi1ELi1EEi
void (*p2)(int) = &qux;
- // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXLi1EEEi
+ // CHECK: store void (i32)* @_Z3q
[llvm-branch-commits] [clang] 241275a - Revert "[Clang] Propagate guaranteed alignment for malloc and others"
Author: James Y Knight
Date: 2022-02-08T17:16:19-05:00
New Revision: 241275a01ed88cd59d503449a8c74a3b7cfedbb2
URL:
https://github.com/llvm/llvm-project/commit/241275a01ed88cd59d503449a8c74a3b7cfedbb2
DIFF:
https://github.com/llvm/llvm-project/commit/241275a01ed88cd59d503449a8c74a3b7cfedbb2.diff
LOG: Revert "[Clang] Propagate guaranteed alignment for malloc and others"
The above change assumed that malloc (and friends) would always
allocate memory to getNewAlign(), even for allocations which have a
smaller size. This is not actually required by spec (a 1-byte
allocation may validly have 1-byte alignment).
Some real-world malloc implementations do not provide this guarantee,
and thus this optimization is breaking programs.
Fixes #53540
This reverts commit c2297544c04764237cedc523083c7be2fb3833d4.
Differential Revision: https://reviews.llvm.org/D118804
(cherry picked from commit 9545976ff160e19805a84a06a7e59d446f9994d9)
Added:
Modified:
clang/include/clang/Basic/TargetInfo.h
clang/lib/Sema/SemaDecl.cpp
clang/test/CodeGen/alloc-fns-alignment.c
Removed:
diff --git a/clang/include/clang/Basic/TargetInfo.h
b/clang/include/clang/Basic/TargetInfo.h
index a49342a34f3e8..e7db877f4e2bc 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -644,8 +644,8 @@ class TargetInfo : public virtual TransferrableTargetInfo,
}
/// Return the largest alignment for which a suitably-sized allocation with
- /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
- /// correctly-aligned pointer.
+ /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
+ /// pointer.
unsigned getNewAlign() const {
return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
}
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index cbd9df4d6a7b7..bcadf4139046c 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -15319,24 +15319,7 @@ void Sema::AddKnownFunctionAttributes(FunctionDecl
*FD) {
if (!FD->hasAttr())
FD->addAttr(AllocAlignAttr::CreateImplicit(Context, ParamIdx(1, FD),
FD->getLocation()));
- LLVM_FALLTHROUGH;
-case Builtin::BIcalloc:
-case Builtin::BImalloc:
-case Builtin::BImemalign:
-case Builtin::BIrealloc:
-case Builtin::BIstrdup:
-case Builtin::BIstrndup: {
- if (!FD->hasAttr()) {
-unsigned NewAlign = Context.getTargetInfo().getNewAlign() /
-Context.getTargetInfo().getCharWidth();
-IntegerLiteral *Alignment = IntegerLiteral::Create(
-Context, Context.MakeIntValue(NewAlign, Context.UnsignedIntTy),
-Context.UnsignedIntTy, FD->getLocation());
-FD->addAttr(AssumeAlignedAttr::CreateImplicit(
-Context, Alignment, /*Offset=*/nullptr, FD->getLocation()));
- }
break;
-}
default:
break;
}
diff --git a/clang/test/CodeGen/alloc-fns-alignment.c
b/clang/test/CodeGen/alloc-fns-alignment.c
index 8ab0610accf03..31dc9bb2d759d 100644
--- a/clang/test/CodeGen/alloc-fns-alignment.c
+++ b/clang/test/CodeGen/alloc-fns-alignment.c
@@ -1,11 +1,9 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s |
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm < %s |
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s |
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -emit-llvm < %s |
FileCheck %s --check-prefix=ALIGN8
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc
-emit-llvm < %s | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc
-emit-llvm < %s | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc
-emit-llvm < %s | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-aligned_alloc
-emit-llvm < %s | FileCheck %s --check-prefix=NOBUILTIN-ALIGNED_ALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s |
FileCheck %s
+
+// Note: this test originally asserted that malloc/calloc/realloc got alignment
+// attributes on their return pointer. However, that was reverted in
+// https://reviews.llvm.org/D118804 and it now asserts that they do _NOT_ get
+// align attributes.
typedef __SIZE_TYPE__ size_t;
@@ -39,43 +37,29 @@ void *aligned_alloc_large_constant_test(size_t n) {
}
// CHECK-LABEL: @malloc_test
-// ALIGN16: align 16 i8* @malloc
-
-// CHECK-LABEL: @calloc_test
-// ALIGN16: align 16 i8* @calloc
-
-// CHECK-LABEL: @realloc_test
-// ALIGN16: align 16 i8* @reallo
[llvm-branch-commits] [clang] 4ddf140 - Fix PR35902: incorrect alignment used for ubsan check.
Author: James Y Knight
Date: 2020-12-28T18:11:17-05:00
New Revision: 4ddf140c00408ecee9d20f4470e69e0f696d8f8a
URL:
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a
DIFF:
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a.diff
LOG: Fix PR35902: incorrect alignment used for ubsan check.
UBSan was using the complete-object align rather than nv alignment
when checking the "this" pointer of a method.
Furthermore, CGF.CXXABIThisAlignment was also being set incorrectly,
due to an incorrectly negated test. The latter doesn't appear to have
had any impact, due to it not really being used anywhere.
Differential Revision: https://reviews.llvm.org/D93072
Added:
Modified:
clang/lib/CodeGen/CGCXXABI.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/test/CodeGenCXX/catch-undef-behavior.cpp
Removed:
diff --git a/clang/lib/CodeGen/CGCXXABI.cpp b/clang/lib/CodeGen/CGCXXABI.cpp
index 9d5ebdeff35b..9714730e3c4b 100644
--- a/clang/lib/CodeGen/CGCXXABI.cpp
+++ b/clang/lib/CodeGen/CGCXXABI.cpp
@@ -135,8 +135,8 @@ void CGCXXABI::buildThisParam(CodeGenFunction &CGF,
FunctionArgList ¶ms) {
// down to whether we know it's a complete object or not.
auto &Layout = CGF.getContext().getASTRecordLayout(MD->getParent());
if (MD->getParent()->getNumVBases() == 0 || // avoid vcall in common case
- MD->getParent()->hasAttr() ||
- !isThisCompleteObject(CGF.CurGD)) {
+ MD->getParent()->isEffectivelyFinal() ||
+ isThisCompleteObject(CGF.CurGD)) {
CGF.CXXABIThisAlignment = Layout.getAlignment();
} else {
CGF.CXXABIThisAlignment = Layout.getNonVirtualAlignment();
diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp
b/clang/lib/CodeGen/CodeGenFunction.cpp
index 005ee74c1876..a8a91c59ff2d 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -1137,11 +1137,9 @@ void CodeGenFunction::StartFunction(GlobalDecl GD,
QualType RetTy,
MD->getParent()->getLambdaCaptureDefault() == LCD_None)
SkippedChecks.set(SanitizerKind::Null, true);
- EmitTypeCheck(isa(MD) ? TCK_ConstructorCall
-: TCK_MemberCall,
-Loc, CXXABIThisValue, ThisTy,
-getContext().getTypeAlignInChars(ThisTy->getPointeeType()),
-SkippedChecks);
+ EmitTypeCheck(
+ isa(MD) ? TCK_ConstructorCall : TCK_MemberCall,
+ Loc, CXXABIThisValue, ThisTy, CXXABIThisAlignment, SkippedChecks);
}
}
diff --git a/clang/test/CodeGenCXX/catch-undef-behavior.cpp
b/clang/test/CodeGenCXX/catch-undef-behavior.cpp
index 28c92ba8a1a9..a75b9d455d7c 100644
--- a/clang/test/CodeGenCXX/catch-undef-behavior.cpp
+++ b/clang/test/CodeGenCXX/catch-undef-behavior.cpp
@@ -430,8 +430,8 @@ namespace VBaseObjectSize {
// Note: C is laid out such that offsetof(C, B) + sizeof(B) extends outside
// the C object.
struct alignas(16) A { void *a1, *a2; };
- struct B : virtual A { void *b; };
- struct C : virtual A, virtual B {};
+ struct B : virtual A { void *b; void* g(); };
+ struct C : virtual A, virtual B { };
// CHECK-LABEL: define {{.*}} @_ZN15VBaseObjectSize1fERNS_1BE(
B &f(B &b) {
// Size check: check for nvsize(B) == 16 (do not require size(B) == 32)
@@ -443,6 +443,15 @@ namespace VBaseObjectSize {
// CHECK: and i64 [[PTRTOINT]], 7,
return b;
}
+
+ // CHECK-LABEL: define {{.*}} @_ZN15VBaseObjectSize1B1gEv(
+ void *B::g() {
+// Ensure that the check on the "this" pointer also uses the proper
+// alignment. We should be using nvalign(B) == 8, not 16.
+// CHECK: [[PTRTOINT:%.+]] = ptrtoint {{.*}} to i64,
+// CHECK: and i64 [[PTRTOINT]], 7
+return nullptr;
+ }
}
namespace FunctionSanitizerVirtualCalls {
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] 145cbef - Copy demangle changes from libcxxabi to llvm with cp_to_llvm.sh.
Author: James Y Knight
Date: 2020-12-29T16:18:10-05:00
New Revision: 145cbef5879c7fba8bacc2f78cfa426400f52f42
URL:
https://github.com/llvm/llvm-project/commit/145cbef5879c7fba8bacc2f78cfa426400f52f42
DIFF:
https://github.com/llvm/llvm-project/commit/145cbef5879c7fba8bacc2f78cfa426400f52f42.diff
LOG: Copy demangle changes from libcxxabi to llvm with cp_to_llvm.sh.
This includes changes from these commits:
5641b1dfddff847f7f3edc484537f9314c283225
8d313927539de66808e5bf3566fbd844aa78a916
Added:
Modified:
llvm/include/llvm/Demangle/ItaniumDemangle.h
llvm/include/llvm/Demangle/Utility.h
Removed:
diff --git a/llvm/include/llvm/Demangle/ItaniumDemangle.h
b/llvm/include/llvm/Demangle/ItaniumDemangle.h
index cef61756ef09..6bfc02d15379 100644
--- a/llvm/include/llvm/Demangle/ItaniumDemangle.h
+++ b/llvm/include/llvm/Demangle/ItaniumDemangle.h
@@ -2371,9 +2371,9 @@ template struct
AbstractManglingParser {
TemplateParamList Params;
public:
-ScopedTemplateParamList(AbstractManglingParser *Parser)
-: Parser(Parser),
- OldNumTemplateParamLists(Parser->TemplateParams.size()) {
+ScopedTemplateParamList(AbstractManglingParser *TheParser)
+: Parser(TheParser),
+ OldNumTemplateParamLists(TheParser->TemplateParams.size()) {
Parser->TemplateParams.push_back(&Params);
}
~ScopedTemplateParamList() {
@@ -5223,7 +5223,7 @@ Node *AbstractManglingParser::parseEncoding() {
decltype(TemplateParams) OldParams;
public:
-SaveTemplateParams(AbstractManglingParser *Parser) : Parser(Parser) {
+SaveTemplateParams(AbstractManglingParser *TheParser) : Parser(TheParser) {
OldParams = std::move(Parser->TemplateParams);
Parser->TemplateParams.clear();
}
diff --git a/llvm/include/llvm/Demangle/Utility.h
b/llvm/include/llvm/Demangle/Utility.h
index 04e1936ebbe7..846a5f0818e7 100644
--- a/llvm/include/llvm/Demangle/Utility.h
+++ b/llvm/include/llvm/Demangle/Utility.h
@@ -52,7 +52,7 @@ class OutputStream {
char *TempPtr = std::end(Temp);
while (N) {
- *--TempPtr = '0' + char(N % 10);
+ *--TempPtr = char('0' + N % 10);
N /= 10;
}
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] 8a43809 - Remove TwoAddressInstructionPass::sink3AddrInstruction.
Author: James Y Knight
Date: 2020-07-17T16:29:56-04:00
New Revision: 8a438096ffa48dadeb73b78844c53a7428aaec20
URL:
https://github.com/llvm/llvm-project/commit/8a438096ffa48dadeb73b78844c53a7428aaec20
DIFF:
https://github.com/llvm/llvm-project/commit/8a438096ffa48dadeb73b78844c53a7428aaec20.diff
LOG: Remove TwoAddressInstructionPass::sink3AddrInstruction.
This function has a bug which will incorrectly reschedule instructions
after an INLINEASM_BR (which can branch). (The bug may also allow
scheduling past a throwing-CALL, I'm not certain.)
I could fix that bug, but, as the removed FIXME notes, it's better to
attempt rescheduling before converting to 3-addr form, as that may
remove the need to convert in the first place. In fact, the code to do
such reordering was added to this pass only a few months later, in
2011, via the addition of the function rescheduleMIBelowKill. That
code does not contain the same bug.
The removal of the sink3AddrInstruction function is not a no-op: in
some cases it would move an instruction post-conversion, when
rescheduleMIBelowKill would not move the instruction pre-converison.
However, this does not appear to be important: the machine instruction
scheduler can reorder the after-conversion instructions, in any case.
This patch fixes a kernel panic 4.4 LTS x86_64 Linux kernels, when
built with clang after 4b0aa5724feaa89a9538dcab97e018110b0e4bc3.
Link: https://github.com/ClangBuiltLinux/linux/issues/1085
Differential Revision: https://reviews.llvm.org/D83708
(cherry picked from commit 60433c63acb71935111304d71e41b7ee982398f8)
Added:
llvm/test/CodeGen/X86/callbr-asm-sink.ll
Modified:
llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
llvm/test/CodeGen/X86/masked-iv-unsafe.ll
llvm/test/CodeGen/X86/reverse_branches.ll
llvm/test/CodeGen/X86/rotate-extract.ll
llvm/test/CodeGen/X86/twoaddr-lea.ll
Removed:
llvm/test/CodeGen/X86/twoaddr-pass-sink.ll
diff --git a/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
b/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
index de336abe607a..615ff4b8789c 100644
--- a/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
+++ b/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp
@@ -70,7 +70,6 @@ STATISTIC(NumTwoAddressInstrs, "Number of two-address
instructions");
STATISTIC(NumCommuted, "Number of instructions commuted to coalesce");
STATISTIC(NumAggrCommuted, "Number of instructions aggressively commuted");
STATISTIC(NumConvertedTo3Addr, "Number of instructions promoted to 3-address");
-STATISTIC(Num3AddrSunk,"Number of 3-address instructions sunk");
STATISTIC(NumReSchedUps, "Number of instructions re-scheduled up");
STATISTIC(NumReSchedDowns, "Number of instructions re-scheduled down");
@@ -109,10 +108,6 @@ class TwoAddressInstructionPass : public
MachineFunctionPass {
// Set of already processed instructions in the current block.
SmallPtrSet Processed;
- // Set of instructions converted to three-address by target and then sunk
- // down current basic block.
- SmallPtrSet SunkInstrs;
-
// A map from virtual registers to physical registers which are likely
targets
// to be coalesced to due to copies from physical registers to virtual
// registers. e.g. v1024 = move r0.
@@ -123,9 +118,6 @@ class TwoAddressInstructionPass : public
MachineFunctionPass {
// registers. e.g. r1 = move v1024.
DenseMap DstRegMap;
- bool sink3AddrInstruction(MachineInstr *MI, unsigned Reg,
-MachineBasicBlock::iterator OldPos);
-
bool isRevCopyChain(unsigned FromReg, unsigned ToReg, int Maxlen);
bool noUseAfterLastDef(unsigned Reg, unsigned Dist, unsigned &LastDef);
@@ -209,136 +201,6 @@ INITIALIZE_PASS_END(TwoAddressInstructionPass, DEBUG_TYPE,
static bool isPlainlyKilled(MachineInstr *MI, unsigned Reg, LiveIntervals
*LIS);
-/// A two-address instruction has been converted to a three-address instruction
-/// to avoid clobbering a register. Try to sink it past the instruction that
-/// would kill the above mentioned register to reduce register pressure.
-bool TwoAddressInstructionPass::
-sink3AddrInstruction(MachineInstr *MI, unsigned SavedReg,
- MachineBasicBlock::iterator OldPos) {
- // FIXME: Shouldn't we be trying to do this before we three-addressify the
- // instruction? After this transformation is done, we no longer need
- // the instruction to be in three-address form.
-
- // Check if it's safe to move this instruction.
- bool SeenStore = true; // Be conservative.
- if (!MI->isSafeToMove(AA, SeenStore))
-return false;
-
- unsigned DefReg = 0;
- SmallSet UseRegs;
-
- for (const MachineOperand &MO : MI->operands()) {
-if (!MO.isReg())
- continue;
-Register MOReg = MO.getReg();
-if (!MOReg)
- continue;
-if (MO.isUse() && MOReg != SavedReg)
- UseRegs.insert(MO.getReg());
-if (!MO.isDef
[llvm-branch-commits] [llvm-tag] r349860 - Remove old misnamed tag ("final" was created right afterwards).
Author: jyknight
Date: Thu Dec 20 15:48:45 2018
New Revision: 349860
URL: http://llvm.org/viewvc/llvm-project?rev=349860&view=rev
Log:
Remove old misnamed tag ("final" was created right afterwards).
Removed:
llvm/tags/RELEASE_351/Final/
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/20.x: [clang] Parse warning-suppression-mapping after setting up diagengine (#125714) (PR #126030)
https://github.com/jyknight approved this pull request. https://github.com/llvm/llvm-project/pull/126030 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/20.x: [clang] Stop parsing warning suppression mappings in driver (#125722) (PR #126027)
https://github.com/jyknight approved this pull request. https://github.com/llvm/llvm-project/pull/126027 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SelectionDAG] Legalize <1 x T> vector types for atomic load (PR #120385)
jyknight wrote:
Running `llc -mtriple=x86_64-linux-gnu` on
```
define <2 x i32> @atomic_vec2_i32(ptr %x) #0 {
%ret = load atomic <2 x i32>, ptr %x acquire, align 64
ret <2 x i32> %ret
}
```
crashes with:
```
WidenVectorResult #0: t3: v2i32,ch = AtomicLoad<(load acquire (s64) from %ir.x,
align 64)> t0, t2
LLVM ERROR: Do not know how to widen the result of this operator!
```
https://github.com/llvm/llvm-project/pull/120385
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [X86] Manage atomic load of fp -> int promotion in DAG (PR #120386)
@@ -2595,6 +2595,10 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, setOperationAction(Op, MVT::f32, Promote); } + setOperationPromotedToType(ISD::ATOMIC_LOAD, MVT::f16, MVT::i16); jyknight wrote: Presumably similar changes to other backends are also required? https://github.com/llvm/llvm-project/pull/120386 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [X86] Add atomic vector tests for >1 sizes. (PR #120387)
jyknight wrote: > Atomic vectors with size >1 are lowered to calls. That's not true; they're only lowered to calls when the alignment is not known to be sufficient (e.g. `<2 x i32>` must have `align 8`, not `align 4`). https://github.com/llvm/llvm-project/pull/120387 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SelectionDAG] Legalize <1 x T> vector types for atomic load (PR #120385)
jyknight wrote: > At this PR, this is the expectation. A later PR needs to handle the other > vector legalization cases Well, it also doesn't work after the rest of the series. As a general comment, I find it difficult to review a series of PRs where the intermediate state between them is broken, and without any clear indication as to what is and isn't supposed to work after each PR. If this set of changes is going to remain split up into multiple PRs, the descriptions need to make it clear what's the expected state after each one, so I don't need to guess as to which of the PRs to leave a comment like that on... https://github.com/llvm/llvm-project/pull/120385 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SelectionDAG] Legalize <1 x T> vector types for atomic load (PR #120385)
jyknight wrote: > The tests posted in the review work from that point on, except [...] Sure, I agree that the tests which have been added pass. But the tests do not currently test everything necessary for this feature to be complete. What I see here is a series of PRs each adding some part of a full implementation of this feature, and some corresponding tests for those pieces. But, at the moment it looks like just a bunch of individual pieces of work, not a whole picture of where this is going. I can't tell if missing/broken functionality is missing because you hadn't thought of it yet, or because this PR series does not yet contain all the work you know you will need to eventually do, or what. If breaking work up into a series of PRs, the series needs to tell an understandable story. E.g., it could be something like this: - New IR allowed in the verifier. It will not yet compile, but bitcode/textual IR creation/reading/writing works. - AtomicExpandPass handles vector types correctly. Now the IR-level transform works; backend target lowering still broken. - Generic SelectionDAG legalization support added. (prerequisite work for next PRs) - X86 backend support. Now, `store atomic ` and `load atomic ` should correctly compile on x86/x86_64 platforms (for all N and T), when using SelectionDAG. - GlobalISel - Other targets - Now, the new operations are fully functional. (I'm not saying it has to be exactly _that_ split, it's just an example.) https://github.com/llvm/llvm-project/pull/120385 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
