[llvm-bugs] [Bug 47664] New: LLVM ERROR: unsupported libcall legalization in clang-11
https://bugs.llvm.org/show_bug.cgi?id=47664 Bug ID: 47664 Summary: LLVM ERROR: unsupported libcall legalization in clang-11 Product: clang Version: 11.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: marcus.wag...@hpe.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, marcus.wag...@hpe.com, richard-l...@metafoo.co.uk ``` Please, note that this bug categorization is the best I could come up with. If this should not be submitted under "clang", please, re-classify as needed. During a debug build with optimization level -O0 of a test case of the AMReX software framework using the software environment modules (gcc/9.2.0, mpich/ge/gcc/64/3.3.2, rocm/3.7.0) an "LLVM ERROR: unsupported libcall legalization" occurred, which resulted in a core dump and in the crash backtrace shown below. This error did not occur when the optimization level was changed from -O0 to -O3, where the latter case worked. Also, when rocm/3.7.0 was swapped out for rocm/3.8.0, this compiler error no longer resulted in a crash and a core dump. Instead, the error message was then fatal error: error in backend: unsupported libcall legalization clang-11: error: clang frontend command failed with exit code 70 (use -v to see invocation) Here is the signature of the more severe form of presumably the same compiler error: LLVM ERROR: unsupported libcall legalization PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/rocm-3.7.0/llvm/bin/llc /tmp/CNS_advance-1a7add-gfx906-optimized-caf2ef.bc -O0 -mtriple=amdgcn-amd-amdhsa -mcpu=gfx906 -filetype=obj -o /tmp/CNS_advance-1a7add-gfx906-2df49d.o 1. Running pass 'CallGraph Pass Manager' on module '/tmp/CNS_advance-1a7add-gfx906-optimized-caf2ef.bc'. 2. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@_Z11cns_ctoprimiiiRKN5amrex6Array4IKdEERKNS0_IdEERK4Parm' #0 0x019c929a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/opt/rocm-3.7.0/llvm/bin/llc+0x19c929a) #1 0x019c70a4 llvm::sys::RunSignalHandlers() (/opt/rocm-3.7.0/llvm/bin/llc+0x19c70a4) #2 0x019c71e3 SignalHandler(int) (/opt/rocm-3.7.0/llvm/bin/llc+0x19c71e3) #3 0x1511ddd0 __restore_rt (/lib64/libpthread.so.0+0x12dd0) #4 0x13bb670f raise (/lib64/libc.so.6+0x3770f) #5 0x13ba0b25 abort (/lib64/libc.so.6+0x21b25) #6 0x0194c248 llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/rocm-3.7.0/llvm/bin/llc+0x194c248) #7 0x0194c368 (/opt/rocm-3.7.0/llvm/bin/llc+0x194c368) #8 0x008239c6 (/opt/rocm-3.7.0/llvm/bin/llc+0x8239c6) #9 0x017bd8bd llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) const (/opt/rocm-3.7.0/llvm/bin/llc+0x17bd8bd) #10 0x01882097 llvm::TargetLowering::makeLibCall(llvm::SelectionDAG&, llvm::RTLIB::Libcall, llvm::EVT, llvm::ArrayRef, llvm::TargetLowering::MakeLibCallOptions, llvm::SDLoc const&, llvm::SDValue) const (/opt/rocm-3.7.0/llvm/bin/llc+0x1882097) #11 0x01883b95 llvm::TargetLowering::expandMULO(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&, llvm::SelectionDAG&) const (/opt/rocm-3.7.0/llvm/bin/llc+0x1883b95) #12 0x0178a874 (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode*) (/opt/rocm-3.7.0/llvm/bin/llc+0x178a874) #13 0x0177fecb (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) (/opt/rocm-3.7.0/llvm/bin/llc+0x177fecb) #14 0x017844df llvm::SelectionDAG::Legalize() (/opt/rocm-3.7.0/llvm/bin/llc+0x17844df) #15 0x01840878 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/rocm-3.7.0/llvm/bin/llc+0x1840878) #16 0x01844adc llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/rocm-3.7.0/llvm/bin/llc+0x1844adc) #17 0x01846c4a llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.803) (/opt/rocm-3.7.0/llvm/bin/llc+0x1846c4a) #18 0x008cf63a (anonymous namespace)::AMDGPUDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/rocm-3.7.0/llvm/bin/llc+0x8cf63a) #19 0x00fb7368 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/opt/rocm-3.7.0/llvm/bin/llc+0xfb7368) #20 0x01340db7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/rocm-3.7.0/llvm/bin/llc+0x1340db7) #21 0x00c4a118 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/opt/rocm-3.7.0/llvm/bin/llc+0xc4a118) #22 0x01341941 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/rocm-3.7.0/llvm/bin/llc+0x1341941) #23 0x006cb15d compileModule(char**, llvm::LLVMContext&) (/opt/rocm-3.7.0/llvm/bin/ll
[llvm-bugs] [Bug 47665] New: float128 argument not passed with va_arg
https://bugs.llvm.org/show_bug.cgi?id=47665
Bug ID: 47665
Summary: float128 argument not passed with va_arg
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: shibatch.sf@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following testcase shows 0 if compiled with -O1 option.
#include
#include
void func(int n, ...) {
va_list ap;
va_start(ap, n);
__float128 q = va_arg(ap, __float128);
va_end(ap);
printf("%g\n", (double)q);
}
int main(void) {
__float128 q = 0.1Q;
func(0, q);
}
$ clang-10 -O1 vargf128.c
$ ./a.out
0
$ clang-10 -O0 vargf128.c
$ ./a.out
0.1
--
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 47666] New: Transfer can be constant value, but not now
https://bugs.llvm.org/show_bug.cgi?id=47666 Bug ID: 47666 Summary: Transfer can be constant value, but not now Product: flang Version: trunk Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedb...@nondot.org Reporter: i.s@ya.ru CC: david.tr...@arm.com, jper...@nvidia.com, kirankuma...@gmail.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com I have tried to compile the following code: real(8), parameter :: zero_int = transfer(0,0D0) end And I have got message: :1:34: error: Must be a constant value real(8), parameter :: zero_int = transfer(0,0D0) ^^^ But in reality, it is a constant value. ifort and gcc can compile this code (See here: https://godbolt.org/z/r83ves) Locally tested version is commit d2166076b882e38becf3657ea830ffd2b6a5695e of llvm-project. -- 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 47667] New: Loop with "# pragma clang loop interleave (enable)" is not interleaved
https://bugs.llvm.org/show_bug.cgi?id=47667
Bug ID: 47667
Summary: Loop with "# pragma clang loop interleave (enable)" is
not interleaved
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: fj876...@aa.jp.fujitsu.com
CC: llvm-bugs@lists.llvm.org
If you write "# pragma loop interleave (enable)" and "# pragma loop vectorize
(enable)" on the loop, the behavior is the same.
The reason is that they both create metadata like this:.
!8 = !{!"llvm.loop.vectorize.enable", i1 true}
Users will write these pragmas if they want to vectorize or interleave.
However, if "# pragma clang loop interleave (enable)" is specified, it is not
interleaved.
I think it should be interleaved. What do you think?
I think we should do one of the following two things.
* When the metadata described above exists, apply both vectorization and
interleaving.
* Create and control separate metadata for each.
It seems that interleaving is not controlled by the pragma but controlled by
the -funroll-loops option.
By the way, "# pragma clang loop interleave (disable)" is controlled by the
following metadata, so there is no problem.
!25 = !{!"llvm.loop.interleave.count", i32 1}
- interleave.c :
void foo(double * restrict a,
double * restrict b,
double * restrict c,
int n) {
#pragma clang loop interleave(enable)
for (int i=0;i___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47619, which changed state. Bug 47619 Summary: regression with aarch64-linux: UNREACHABLE executed at ../include/llvm/Support/MachineValueType.h:756 https://bugs.llvm.org/show_bug.cgi?id=47619 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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 47619] regression with aarch64-linux: UNREACHABLE executed at ../include/llvm/Support/MachineValueType.h:756
https://bugs.llvm.org/show_bug.cgi?id=47619 Hans Wennborg changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Hans Wennborg --- (In reply to Matt Arsenault from comment #13) > (In reply to Matt Arsenault from comment #12) > > (In reply to Matt Arsenault from comment #11) > > > The testcase now hits a verifier error, so this needs an additional fix > > > > https://reviews.llvm.org/D88306 > > Committed 6cb0d23f2ea6fb25106b0380797ccbc2141d71e1 Thanks again! Pushed to 11.x as 184a13d362e041b1fcd14a5e782ba0b17d13dc3c. -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47630, which changed state. Bug 47630 Summary: regression with mips-linux: Assertion `ShiftAmt <= BitWidth && "Invalid shift amount"' failed https://bugs.llvm.org/show_bug.cgi?id=47630 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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 47630] regression with mips-linux: Assertion `ShiftAmt <= BitWidth && "Invalid shift amount"' failed
https://bugs.llvm.org/show_bug.cgi?id=47630 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Hans Wennborg --- (In reply to Simon Atanasyan from comment #5) > The bug is fixed at c6c5629. I think it's safe to backport it to the release > branch. Pushed to 11.x as 1e4b179bf821bfff8fad7f46423494ed1f62dac0. Many thanks! -- 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 47668] New: foldSelectICmpAndAnd should check whether the shift amount is less than bitwidth
https://bugs.llvm.org/show_bug.cgi?id=47668
Bug ID: 47668
Summary: foldSelectICmpAndAnd should check whether the shift
amount is less than bitwidth
Product: libraries
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
File: test/Transforms/InstCombine/select-of-bittest.ll
```
define i32 @f_var2(i32 %arg, i32 %arg1) {
%0:
%tmp = and i32 %arg, 1
%tmp2 = icmp eq i32 %tmp, 0
%tmp3 = lshr i32 %arg, %arg1
%tmp4 = and i32 %tmp3, 1
%tmp5 = select i1 %tmp2, i32 %tmp4, i32 1
ret i32 %tmp5
}
=>
define i32 @f_var2(i32 %arg, i32 %arg1) {
%0:
%1 = shl i32 1, %arg1
%2 = or i32 %1, 1
%3 = and i32 %2, %arg
%4 = icmp ne i32 %3, 0
%tmp5 = zext i1 %4 to i32
ret i32 %tmp5
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i32 %arg = #x0001 (1)
i32 %arg1 = poison
Source:
i32 %tmp = #x0001 (1)
i1 %tmp2 = #x0 (0)
i32 %tmp3 = poison
i32 %tmp4 = poison
i32 %tmp5 = #x0001 (1)
Target:
i32 %1 = poison
i32 %2 = poison
i32 %3 = poison
i1 %4 = poison
i32 %tmp5 = poison
Source value: #x0001 (1)
Target value: poison
```
Relevant revision: https://reviews.llvm.org/D45108
The revision includes Alive proof, but its precondition wasn't encoded.
I'll make a patch for this.
--
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 47297] Assertion `false && "Pass modifies its input and doesn't report it."' for -jump-threading pass
https://bugs.llvm.org/show_bug.cgi?id=47297 David Stenberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from David Stenberg --- Closing this ticket since the JumpThreading bug is resolved. rGbfcb824ba528. -- 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 47247] Unroll small loops implied by llvm.assume
https://bugs.llvm.org/show_bug.cgi?id=47247 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||0ad793f321ed --- Comment #8 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rG0ad793f321ed -- 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 47669] New: It is slower to use std::string::operator+= with a char literal argument than a string literal
https://bugs.llvm.org/show_bug.cgi?id=47669
Bug ID: 47669
Summary: It is slower to use std::string::operator+= with a
char literal argument than a string literal
Product: libc++
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pierre.tallo...@viacesi.fr
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
There is clang-tidy option performance-faster-string-find that detects the use
of the std::basic_string::find method (and related ones) with a single
character string literal as argument. According to it, the use of a character
literal is more efficient.
However, I performed a benchmark and noticed it is the case only for small
string (when the small string optimization is used).
Here is my code:
#include
#include
static void BM_string_literal(benchmark::State& state)
{
std::string s;
for (int i = 0; i < state.range(0); i++)
s += 'a';
s += 'b';
benchmark::DoNotOptimize(s.data());
benchmark::ClobberMemory();
size_t pos;
for (auto _ : state)
{
benchmark::DoNotOptimize(pos = s.find("b")); // "b" is a string
literal, it should be longer
benchmark::ClobberMemory();
}
}
BENCHMARK(BM_string_literal)->RangeMultiplier(2)->Range(8, 8<<10);
static void BM_char_literal(benchmark::State& state)
{
std::string s;
for (int i = 0; i < state.range(0); i++)
s += 'a';
s += 'b';
benchmark::DoNotOptimize(s.data());
benchmark::ClobberMemory();
size_t pos;
for (auto _ : state)
{
benchmark::DoNotOptimize(pos = s.find('b')); // 'b' is a char literal,
it should be faster
benchmark::ClobberMemory();
}
}
BENCHMARK(BM_char_literal)->RangeMultiplier(2)->Range(8, 8<<10);
BENCHMARK_MAIN();
According to clang-tidy, I should prefer the code in BM_char_literal which is
faster. However, the results of the benchmark are the following:
[BM_string_literal vs. BM_char_literal]/8 -0.0760
-0.0760 9 89 8
[BM_string_literal vs. BM_char_literal]/16 -0.0757
-0.0767 9 89 8
[BM_string_literal vs. BM_char_literal]/32 +0.3812
+0.3809 4 54 5
[BM_string_literal vs. BM_char_literal]/64 +0.1609
+0.1602 4 54 5
[BM_string_literal vs. BM_char_literal]/128 +0.1946
+0.1944 4 54 5
[BM_string_literal vs. BM_char_literal]/256 +0.1616
+0.1623 6 66 6
[BM_string_literal vs. BM_char_literal]/512 +0.2225
+0.2211 7 97 9
[BM_string_literal vs. BM_char_literal]/1024+0.1052
+0.105111121112
[BM_string_literal vs. BM_char_literal]/2048+0.0789
+0.078118201820
[BM_string_literal vs. BM_char_literal]/4096+0.0349
+0.034831323132
[BM_string_literal vs. BM_char_literal]/8192+0.0053
+0.004256575657
We can see it is faster using a string_literal when the std::string is at least
32 characters long (I can reproduce these results again and again, it is not a
variance issue).
Is clang-tidy wrong or is there a bug in libc++? Or is my benchmark wrong
somewhere?
To reproduce my case, here are the commands I used (on a debian-stable):
apt-get -y install clang libc++-dev libc++abi-dev git cmake python python-pip
git clone https://github.com/google/benchmark.git
git clone https://github.com/google/googletest.git benchmark/googletest
pushd benchmark
cmake -E make_directory "build"
cmake -E chdir "build" cmake -DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release
-DCMAKE_CXX_FLAGS="-stdlib=libc++" -DBENCHMARK_DOWNLOAD_DEPENDENCIES=ON ../
cmake --build "build" --config Release --target install
popd
pip install scipy
clang++ -stdlib=libc++ -O3 bench.cpp -lbenchmark -lpthread -o bench
./benchmark/tools/compare.py filters ./bench BM_string_literal BM_char_literal
--
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 26006 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26006 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26006#c1 ClusterFuzz testcase 5154639627157504 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009270601:202009280603 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 46258] [AArch64] Some functions compiled without BTI with -fsanitize=cfi
https://bugs.llvm.org/show_bug.cgi?id=46258 Daniel Kiss changed: What|Removed |Added Fixed By Commit(s)||a88c722e687e Product|new-bugs|clang CC||neeil...@live.com, ||richard-l...@metafoo.co.uk Status|CONFIRMED |RESOLVED Component|new bugs|LLVM Codegen Assignee|pe...@pcc.me.uk |daniel.k...@arm.com Resolution|--- |FIXED --- Comment #2 from Daniel Kiss --- patches got merged. -- 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 46480] [AArch64] .note.gnu.property always generated for object file without code
https://bugs.llvm.org/show_bug.cgi?id=46480 Daniel Kiss changed: What|Removed |Added Fixed By Commit(s)||a48f6079f288 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 46480, which changed state. Bug 46480 Summary: [AArch64] .note.gnu.property always generated for object file without code https://bugs.llvm.org/show_bug.cgi?id=46480 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 47670] New: No loop vectorization for loop guarded by condition
https://bugs.llvm.org/show_bug.cgi?id=47670
Bug ID: 47670
Summary: No loop vectorization for loop guarded by condition
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
No vectorization:
unsigned sum_small(unsigned data[], bool b) {
unsigned sum = 0;
if (b) {
for (int i = 0; i < 32; ++i) {
sum += data[i];
}
}
return sum;
}
Vectorized:
unsigned sum_small(unsigned data[], bool b) {
unsigned sum = 0;
// if (b) {
for (int i = 0; i < 32; ++i) {
sum += data[i];
}
// }
return sum;
}
https://godbolt.org/z/oWPf9x
--
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 23957 in oss-fuzz: llvm:clang-format-fuzzer: ASSERT: idx < size()
Updates: Labels: Deadline-Approaching Comment #1 on issue 23957 by sheriffbot: llvm:clang-format-fuzzer: ASSERT: idx < size() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23957#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 23908 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: UserValue <= UserMaxValue && "value is too big"
Updates: Labels: Deadline-Approaching Comment #1 on issue 23908 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: UserValue <= UserMaxValue && "value is too big" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23908#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 47556] Constructor homing missing anonymous union
https://bugs.llvm.org/show_bug.cgi?id=47556 Amy Huang changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 47671] New: missing loop unrolling and vectorization for loop with peeled branch
https://bugs.llvm.org/show_bug.cgi?id=47671
Bug ID: 47671
Summary: missing loop unrolling and vectorization for loop with
peeled branch
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Testcase (x86_64):
int broken_sum(int *p, int *q) {
bool first = true;
int sum = 0;
while (p != q) {
if (!first) {
sum += 2;
}
sum += *p;
first = false;
++p;
}
return sum;
}
We peel off the first ('first == true') iteration, but don't unroll or
vectorize the resulting ('first == false') loop [https://godbolt.org/z/9chsMr].
However, if we create that same resulting loop by initializing 'first' to
'false', then we do unroll and vectorize the loop
[https://godbolt.org/z/588ovf].
There's also a potential regression from LLVM 10 to trunk here: under -mno-sse,
with 'first' initialized to 'false', we used to unroll the loop even though we
couldn't vectorize [https://godbolt.org/z/bovvE9], but LLVM trunk does not
unroll the loop under -mno-sse [https://godbolt.org/z/4h3x5b].
--
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 47672] New: No vectorization of constraint fptoui
https://bugs.llvm.org/show_bug.cgi?id=47672 Bug ID: 47672 Summary: No vectorization of constraint fptoui Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: thomas.preudho...@celest.fr CC: llvm-bugs@lists.llvm.org Created attachment 24002 --> https://bugs.llvm.org/attachment.cgi?id=24002&action=edit Testcase for vectorization of fptoui Hi, Vectorization of constrainted fptoui does not happen with this testcase even though it would not generate more exceptions. The output when running opt -O2 -S -mtriple aarch64 -mattr=+neon testcase.ll | llc is as follows: conv_v2f32_to_v2i32: ldr d0, [x0] fcvtzu v0.2s, v0.2s str d0, [x1] ret strict_conv_v2f32_to_v2i32: ldp s0, s1, [x0] fcvtzu w8, s0 fcvtzu w9, s1 stp w8, w9, [x1] ret Why does the function strict_conv_v2f32_to_v2i32 not generate the same output as conv_v2f32_to_v2i32? -- 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 47673] New: GNU extension alignof(expression) incorrectly returns preferred alignment
https://bugs.llvm.org/show_bug.cgi?id=47673 Bug ID: 47673 Summary: GNU extension alignof(expression) incorrectly returns preferred alignment Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: jykni...@google.com CC: blitzrak...@gmail.com, dgre...@apple.com, efrie...@quicinc.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk After adjusting for explicit alignment attributes on a decl, alignof(name) falls back to the _preferred_ alignment of the decl's type. This is broken if the decl isn't actually allocated at preferred alignment. An object will be aligned to the preferred alignment when creating complete objects on the stack or as a global. But, Decls aren't always referring to a newly-created complete object, and in some cases, like function parameters, the alignment can be ABI-mandated to be less than the preferred alignment. To solve this, we could try to be "smart" and return the preferred alignment when we know this to be correct. But, I think it's probably better to simply make alignof(expr) be equivalent to alignof(decltype(var)) adjusted by the explicit alignment attributes on the decl. Some examples of the problems: clang -fsyntax-only -target powerpc-aix -xc++ - <___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47674] New: Clang discards attributes aligned and may_alias for typedefs passed as template arguments
https://bugs.llvm.org/show_bug.cgi?id=47674
Bug ID: 47674
Summary: Clang discards attributes aligned and may_alias for
typedefs passed as template arguments
Product: clang
Version: 10.0
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mte.z...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hello!
Clang discards aligned attribute, applied on a typdef,
when it's passed as a template argument.
Compiler Expolorer:
Clang -> https://godbolt.org/z/x375GT
C++ Source Code:
#include
typedef float vec __attribute__((vector_size(8)));
typedef float fp __attribute__((aligned(16)));
template struct identity { typedef t type; };
int main ()
{
std::cout << sizeof(typename identity::type) << std::endl;
std::cout << sizeof(vec ) << std::endl;
std::cout << alignof(typename identity::type) << std::endl;
std::cout << alignof(fp ) << std::endl;
}
Program Output:
8
8
4
16
The above program shows that alignment of the fp typedef changes,
after it's been passed through the identity meta-function - it's 4-bytes
instead of expected 16-bytes.
What's interesting is not all type attributes are discarded - the vector_size
attribute is preserved after being passed through the identity meta-function.
This behavior is required, since removal of the vector_size attribute
would be a semantic change of the vec type, affecting even its size,
because the vec type would represent a single float,
instead of a vector of 2 floats.
The same could be said about the aligned attribute - discarding it
is also a semantic change, since alignment is a fundamental property of a type,
affecting among others code generation,
that is, two types are not equivalent if they have different alignment.
This is the reason why I argue that, passing a typedef as a template argument
should preserve its aligned attribute, instead of discarding it.
Moreover, the Intel C++ compiler implements this behavior correctly.
Compiler Expolorer:
ICC -> https://godbolt.org/z/9vr9se
Program Output:
8
8
16
16
The issue described above doesn't apply only to the aligned type attribute,
but also to the may_alias type attribute.
Compiler Expolorer:
Clang -> https://godbolt.org/z/zYEz78
C++ Source Code:
#include
#include
typedef float fp __attribute__((may_alias));
template struct identity { typedef T type; };
static_assert( sizeof(float) == sizeof(int) , "");
static_assert(alignof(float) == alignof(int) , "");
static_assert(std::numeric_limits::is_iec559, "");
bool can_alias_float ()
{
const auto fn = [] (float *f, int *i) -> int
{
*i = 0x1;
*f = 2.0f; // In ieee754 bin repr of 2.0f is 0x4000.
return *i;
};
int val; // Casting int* to float* is UB!
val = fn(reinterpret_cast(&val), &val);
return val == 0x4000;
}
bool can_alias_fp ()
{
const auto fn = [] (fp *f, int *i) -> int
{
*i = 0x1;
*f = 2.0f; // In ieee754 bin repr of 2.0f is 0x4000.
return *i;
};
int val; // Casting int* to fp* is OK, due to attribute may_alias.
val = fn(reinterpret_cast(&val), &val);
return val == 0x4000;
}
bool can_alias_identity_type_fp ()
{
const auto fn = [] (typename identity::type *f, int *i) -> int
{
*i = 0x1;
*f = 2.0f; // In ieee754 bin repr of 2.0f is 0x4000.
return *i;
}; // Casting int* to fp* should be OK,
int val; // but the attribute may_alias is discarded, causing UB!
val = fn(reinterpret_cast::type*>(&val), &val);
return val == 0x4000;
}
int main ()
{
std::cout << "fp " << can_alias_fp () <<
'\n';
std::cout << "identity::type " << can_alias_identity_type_fp() <<
'\n';
std::cout << "float " << can_alias_float () <<
'\n';
}
Again, discarding attribute may_alias is a semantic change,
because aliasing rules can affect code generation.
Why this issue is important?
Well, because it prevents generic programming, via C++ templates,
using x86 SIMD types.
If we would look at definitions of x86 SIMD types, we will notice that they are
essentially typedefs with attributes vector_size and may_alias applied on them:
- immintrin.h
typedef float __m256 __attribute__((__vector_size__(32),
__may_alias__));
- emmintrin.h
typedef long long __m128i __attribute__((__vector_size__(16),
__may_alias__));
typedef double__m128d __attribute__((__vector_size__(16),
__may_alias__));
- xmmintrin.h
typedef float
[llvm-bugs] Issue 26041 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-09-29 Type: Bug New issue 26041 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26041 Detailed Report: https://oss-fuzz.com/testcase?key=6012514381594624 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe5475a968 Crash State: clang::DeclContext::lookup LookupDirect clang::Sema::LookupQualifiedName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902260412:201902270426 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6012514381594624 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
