[llvm-bugs] [Bug 52126] New: SLP: missed vectorization due to cost model (benchmark from SPECFP 2006)
https://bugs.llvm.org/show_bug.cgi?id=52126
Bug ID: 52126
Summary: SLP: missed vectorization due to cost model (benchmark
from SPECFP 2006)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
433.milc
typedef struct {
double real;
double imag;
} complex;
typedef struct {
complex e[3][3];
} su3_matrix;
#define CSUM(a, b)\
{ \
(a).real += (b).real; \
(a).imag += (b).imag; \
}
#define CMUL(a, b, c) \
{ \
(c).real = (a).real * (b).real - (a).imag * (b).imag; \
(c).imag = (a).real * (b).imag + (a).imag * (b).real; \
}
void mult_su3_nn2(su3_matrix *a, su3_matrix *b, su3_matrix *c) {
int i, j, k;
complex x, y;
for (i = 0; i < 3; i++)
for (j = 0; j < 3; j++) {
x.real = x.imag = 0.0;
for (k = 0; k < 3; k++) {
CMUL(a->e[i][k], b->e[k][j], y);
CSUM(x, y);
}
c->e[i][j] = x;
}
}
Flags: -Ofast -mavx
https://godbolt.org/z/b6nq5sKaW
example.cpp:10:5: remark: the cost-model indicates that vectorization is not
beneficial [-Rpass-missed=loop-vectorize]
for(i=0;i<3;i++)
^
example.cpp:10:5: remark: the cost-model indicates that interleaving is not
beneficial [-Rpass-missed=loop-vectorize]
GCC/ICC vectorizes mult_su3_nn_unrolled. LLVM does not vectorize it with
AVX/AVX, only with -AVX512 (but does not use vaddsubpd as GCC and ICC do; GCC
recently added pattern detection for addsub to SLP vectorizer)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52127] New: clang -print-multiarch incorrect for linux-musl
https://bugs.llvm.org/show_bug.cgi?id=52127
Bug ID: 52127
Summary: clang -print-multiarch incorrect for linux-musl
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: ch...@arachsys.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25345
--> https://bugs.llvm.org/attachment.cgi?id=25345&action=edit
Fix clang -print-multiarch for -linux-musl targets
clang 13.0.0 has a new option -print-multiarch, matching gcc. On linux-musl
systems this outputs x86_64-linux-gnu (or aarch64-linux-gnu, etc) instead of
x86_64-linux-musl (or aarch64-linux-musl, etc).
Amongst other things, this bug breaks compiling python with clang on musl
hosts, as the python configure script does a sanity check and notices the
output of -print-multiarch is inconsistent with the linux-musl platform triplet
it (correctly) deduces for the host by other means. (The configure script
errors out with "internal configure error for the platform triplet, please file
a bug report" FWIW. This worked okay in clang 12.0.1 because python only checks
the multiarch target for consistency if $CC -print-multiarch isn't an error.)
The implementation in Linux::getMultiarchTriple() of
clang/lib/Driver/ToolChains/Linux.cpp special-cases -linux-android targets, and
assumes -linux-gnu for anything else.
I fixed this locally using the following patch to generalise
Linux::getMultiarchTriple() to cover -linux-musl, shrinking it a little in the
process:
diff --git a/clang/lib/Driver/ToolChains/Linux.cpp
b/clang/lib/Driver/ToolChains/Linux.cpp
index af75b8f07..39f8c1363 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -42,7 +42,8 @@ std::string Linux::getMultiarchTriple(const Driver &D,
StringRef SysRoot) const {
llvm::Triple::EnvironmentType TargetEnvironment =
TargetTriple.getEnvironment();
- bool IsAndroid = TargetTriple.isAndroid();
+ std::string EnvName = TargetTriple.isAndroid() ? "android" :
+TargetTriple.isMusl() ? "musl" : "gnu";
bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
bool IsMipsN32Abi = TargetTriple.getEnvironment() ==
llvm::Triple::GNUABIN32;
@@ -58,78 +59,66 @@ std::string Linux::getMultiarchTriple(const Driver &D,
// regardless of what the actual target triple is.
case llvm::Triple::arm:
case llvm::Triple::thumb:
-if (IsAndroid)
- return "arm-linux-androideabi";
if (TargetEnvironment == llvm::Triple::GNUEABIHF)
- return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+ return "arm-linux-" + EnvName + "eabihf";
+return "arm-linux-" + EnvName + "eabi";
case llvm::Triple::armeb:
case llvm::Triple::thumbeb:
if (TargetEnvironment == llvm::Triple::GNUEABIHF)
- return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+ return "armeb-linux-" + EnvName + "eabihf";
+return "armeb-linux-" + EnvName + "eabi";
case llvm::Triple::x86:
-if (IsAndroid)
- return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux-" + EnvName;
case llvm::Triple::x86_64:
-if (IsAndroid)
- return "x86_64-linux-android";
if (TargetEnvironment == llvm::Triple::GNUX32)
- return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+ return "x86_64-linux-" + EnvName + "x32";
+return "x86_64-linux-" + EnvName;
case llvm::Triple::aarch64:
-if (IsAndroid)
- return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
case llvm::Triple::m68k:
-return "m68k-linux-gnu";
+return "m68k-linux-" + EnvName;
case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-gnu";
+return (IsMipsR6 ? "mipsisa32r6-linux-" : "mips-linux-") + EnvName;
case llvm::Triple::mipsel:
-if (IsAndroid)
- return "mipsel-linux-android";
-return IsMipsR6 ? "mipsisa32r6el-linux-gnu" : "mipsel-linux-gnu";
+return (IsMipsR6 ? "mipsisa32r6el-linux-" : "mipsel-linux-") + EnvName;
case llvm::Triple::mips64: {
std::string MT = std::string(IsMipsR6 ? "mipsisa64r6" : "mips64") +
- "-linux-" + (IsMipsN32Abi ? "gnuabin32" : "gnuabi64");
+ "-linux-" + EnvName + (IsMipsN32Abi ? "abin32" :
"abi64");
if (D.getVFS().exists(SysRoot + "/lib/" + MT))
return MT;
-if (D.getVFS().exists(SysRoot + "/lib/mips64-linux-gnu"))
- return "mips64-linux-gnu";
+if (D.getVFS().exists(SysRoot + "/lib/mips64-linux-" + EnvName))
+ return "mip
[llvm-bugs] [Bug 51995] bionic-snapshot deb packages no longer building since 15th September
https://bugs.llvm.org/show_bug.cgi?id=51995 Carlos Galvez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Carlos Galvez --- This seems to be fixed now! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52128] New: Failure to vectorize accumulation when result is stored in memory
https://bugs.llvm.org/show_bug.cgi?id=52128
Bug ID: 52128
Summary: Failure to vectorize accumulation when result is
stored in memory
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void mac(const int *b, int *sum)
{
int dotp = 0;
for (int i = 0; i < 32; i++)
dotp += b[i];
*sum = dotp;
}
This is not vectorized, but could be. This is done by GCC, but not by LLVM.
PS: Oddly, this can easily be changed to vectorize, but only by making it so
`dotp` is returned instead of stored into memory.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52129] New: [MIPS][microMIPS] Clang fatal error with __atomic_store_n() and microMIPS
https://bugs.llvm.org/show_bug.cgi?id=52129
Bug ID: 52129
Summary: [MIPS][microMIPS] Clang fatal error with
__atomic_store_n() and microMIPS
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jesse.a.degu...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 25346
--> https://bugs.llvm.org/attachment.cgi?id=25346&action=edit
Full crash message and files it request I submit.
int main()
{
volatile int flag = 1;
__atomic_store_n(&flag, 0, __ATOMIC_RELAXED);
//__atomic_store_n(&flag, 0, __ATOMIC_RELEASE);
//__atomic_store_n(&flag, 0, __ATOMIC_SEQ_CST);
//__atomic_load_n(&flag, __ATOMIC_RELAXED);
//__atomic_load_n(&flag, __ATOMIC_ACQUIRE);
//__atomic_load_n(&flag, __ATOMIC_SEQ_CST);
}
Building a file with only the above causes a fatal error when using microMIPS
mode. Here is the command I was using:
clang -target mipsel-gnu-linux-musl -march=mips32r2 -mmicromips -c ./file.c
Here is the error given when the crash occurs:
fatal error: error in backend: Cannot select: 0x721ec10: ch =
AtomicStore<(volatile store monotonic (s32) into %ir.1)> 0x721eba8:1,
FrameIndex:i32<0>, 0x721eba8
0x721e938: i32 = FrameIndex<0>
0x721eba8: i32,ch = load<(dereferenceable load (s32) from %ir.2)>
0x721eb40, FrameIndex:i32<1>, undef:i32
0x721ead8: i32 = FrameIndex<1>
0x721ea08: i32 = undef
I'll attach a ZIP file containing the full stack trace and a couple of other
files the error said to attach.
I originally ran across this when trying to build libc++ for microMIPS mode and
managed to simplify the error case down to the above code. Any of the three
__atomic_store_n() calls above will cause the crash. Removing the "-mmicromips"
option builds without error. Using one of the __atomic_load_n() functions
instead of the __atominc_store_n() seems to not crash and produce reasonable
output using the "sync" instruction.
Playing with the above code on Compiler Explorer using the Clang installs
provided there (the x86 versions seemed to have been build with all targets
supported) suggests that the above code started crashing as of Clang 7.0. Clang
6.0.1 appears to work and generate reasonable assembly.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52130] New: #pragma diagnostic push/pop docs out of date re GCC
https://bugs.llvm.org/show_bug.cgi?id=52130 Bug ID: 52130 Summary: #pragma diagnostic push/pop docs out of date re GCC Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Documentation Assignee: unassignedclangb...@nondot.org Reporter: ojwbe...@gmail.com CC: llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk The clang docs at https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas currently say: > In addition to all of the functionality provided by GCC’s pragma, Clang also > allows you to push and pop the current warning state. And: > That means that it is possible to use push and pop around GCC compatible > diagnostics and Clang will push and pop them appropriately, while GCC will > ignore the pushes and pops as unknown pragmas. This is out-of-date as GCC has implemented `#pragma GCC diagnostic push` and `#pragma GCC diagnostic pop` since 4.6.0 (which was released over 10 years ago): https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52131] New: [X86] Failure to produce chained PAVG's
https://bugs.llvm.org/show_bug.cgi?id=52131 Bug ID: 52131 Summary: [X86] Failure to produce chained PAVG's Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, pengfei.w...@intel.com, spatel+l...@rotateright.com As noted in https://github.com/halide/Halide/pull/6302 https://godbolt.org/z/9nY77r35q Haven't really looked at what is actually going wrong yet, just documenting. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 39827 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-10-11 Type: Bug New issue 39827 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39827 Detailed Report: https://oss-fuzz.com/testcase?key=4694344599207936 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdaf2a6fe0 Crash State: clang::Sema::EmitCurrentDiagnostic clang::Sema::ImmediateDiagBuilder::~ImmediateDiagBuilder clang::Sema::SemaDiagnosticBuilder::~SemaDiagnosticBuilder Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202108030618:202108040600 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4694344599207936 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 39828 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::CreateStoredDeclsMap
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-10-11 Type: Bug New issue 39828 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::CreateStoredDeclsMap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39828 Detailed Report: https://oss-fuzz.com/testcase?key=5336260999249920 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe199e0970 Crash State: clang::DeclContext::CreateStoredDeclsMap clang::DeclContext::makeDeclVisibleInContextImpl clang::DeclContext::buildLookupImpl Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202108010605:202108020602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5336260999249920 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52132] New: LLVM out of memory error when using new pass manager (after emsdk 2.0.17)
https://bugs.llvm.org/show_bug.cgi?id=52132 Bug ID: 52132 Summary: LLVM out of memory error when using new pass manager (after emsdk 2.0.17) Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: wasm Assignee: unassignedb...@nondot.org Reporter: amogh.raic...@autodesk.com CC: llvm-bugs@lists.llvm.org, s...@chromium.org LLVM version: 13.0.0.0-rc1 commit: 31e75512174e1bdaa242ee5c7f30fe56e68c3748 I am using the ninja build system with emscripten. I am able to build my projects successfully with emsdk 2.0.15 and ninja JOB_POOLS_LINK property set to 6 (i.e. max 6 parallel link processes). However, after upgrading to emsdk 2.0.17+ (LLVM 13.0.0.0-rc1), wasm-ld throws LLVM : out of memory exception OR the build process terminates with SIGKILL -9 In this case, I am able to build my projects only if the ninja JOB_POOL_LINK property is set to 2 (i.e. max 2 parallel link processes). Any more than 2 parallel link processes and I get the out of memory error. I observed that using the -Wl, --lto-legacy-pass-manager linker option resolves this issue. I also noticed that the LLVM legacy pass manager was the default setting till 2.0.15, but it was changed to the new LLVM pass manager in 2.0.17. It seems like the new LLVM pass manager is causing increased memory consumption when parallel linker processes are run. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52133] New: duplicate symbol when loading the same framework via macho::parseLCLinkerOption
https://bugs.llvm.org/show_bug.cgi?id=52133 Bug ID: 52133 Summary: duplicate symbol when loading the same framework via macho::parseLCLinkerOption Product: lld Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: zhongkaining.pa...@bytedance.com CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com Created attachment 25347 --> https://bugs.llvm.org/attachment.cgi?id=25347&action=edit As this screenshot shows, the two StringRef instances were supposed to be equal (and they are equal at least before the string data of RHS was released) When loading a framework twice from two object file via macho::parseLCLinkerOption, loadedArchives is not aware that this framework was already loaded, and thus report "error: duplicate symbol". My guess is that this is because when lld was loading this framework for the first time, the string representing the path of the framework was released when lld exits from macho::parseLCLinkerOption, so the StringRef instance representing this framework in DenseMap's bucket becomes an empty string instead of the path of the framework. Therefore, when lld was trying to load this framework for the second time, it finds the bucket for the same key representing the path of the framework, only to find that the key in the bucket is no longer equal to the key used to look up now, because the data in StringRef instance was already released. In line 631 in DenseMap.h, it tries to compare two StringRef instance to see if they are equal by compare their data. However, since the data of the StringRef instance stored in the bucket was released, this comparison function will return false, thus causing loadedArchives cannot recognize that this framework was already loaded. I assume this can be solved by letting the bucket in DenseMap own the string instance using std::string instead of llvm::StringRef, but this could costs lots of space since the string instance is much larger than StringRef. Any advice on this so I can fix this issue? -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
