[llvm-bugs] [Bug 44218] Unable to install clangd-8 and clang-tidy-8 at the same time from LLVM Ubuntu Xenial repositories
https://bugs.llvm.org/show_bug.cgi?id=44218 Sylvestre Ledru changed: What|Removed |Added Status|NEW |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 43165] broken dependencies on lldb-9 on Debian strech
https://bugs.llvm.org/show_bug.cgi?id=43165 Sylvestre Ledru changed: What|Removed |Added CC||sylves...@debian.org Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sylvestre Ledru --- Sorry, I missed that bug. If it is fixed, I will close it. By the way, very interesting! How often do you run it? https://github.com/teeks99/clang-apt-test -- 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 44537] New: incorrect formatting of class in function
https://bugs.llvm.org/show_bug.cgi?id=44537
Bug ID: 44537
Summary: incorrect formatting of class in function
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: janwilm...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
- When a class is used inside a function
- And it inherits from a base class
- And its immediately used
The formatting is really odd, notice
- the mismatched braces of OnTaskExecute
- the mis-alignment of OnTaskAttach
- the incorrect placement of // namespace Foo (its on the wrong closing curly)
Before format:
namespace Foo{
void Bar( const char *Text, const char *Title )
{
class MyErrorBox :
public ErrorBox,
public Foo::CTask::Client
{
public:
MyErrorBox(const char *Text, const char *Title) :
ErrorBox(Text, Title)
{}
void OnTaskExecute(const Foo::CTask *pTask, Foo::uintptr vlaue)
override
{
ErrorBox::OnTaskExecute(pTask, vlaue);
}
void OnTaskAttach(const Foo::CTask *, bool attach) override
{
if (!attach) delete this;
}
} *pBox = new MyErrorBox(Text, Title);
}
}
After format:
namespace Foo {
void Bar(const char * Text, const char * Title)
{
class MyErrorBox : public ErrorBox,
public Foo::CTask::Client{
public:
MyErrorBox(const char * Text, const char *
Title):
ErrorBox(Text, Title){}
void OnTaskExecute(const Foo::CTask * pTask,
Foo::uintptr vlaue) override{
ErrorBox::OnTaskExecute(pTask, vlaue);
}
void OnTaskAttach(const Foo::CTask *, bool attach) override
{
if (!attach)
delete this;
}
} // namespace Foo
*pBox = new MyErrorBox(Text, Title);
}
}
--
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 44538] New: Unsized temporary array problem inside template function
https://bugs.llvm.org/show_bug.cgi?id=44538
Bug ID: 44538
Summary: Unsized temporary array problem inside template
function
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: m.cenc...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Temporary unsized arrays declared inside function template, are treated as
unsized in some contexts, and as sized in others.
I.e. decltype always returns int (&&)[3], but range based for-loop sometimes
treats it as unsized (and incomplete).
Reproducer:
#include
using Array = int[];
template
void bar1(Ts ...values)
{
auto && array1 = Array{ 1, 2, 3 };
auto && array2 = Array{ values...};
static_assert(std::is_same{}, ""); //
ok
static_assert(std::is_same{}, ""); //
ok
for (auto c : array1) {} // ok
for (auto c : array2) {} // does not compile, says array2 has incomplete
type int[]
}
template
void bar2(T1 v1, T2 v2, T3 v3)
{
auto && array1 = Array{ 1, 2, 3 };
auto && array2 = Array{ v1, v2, v3 };
auto && array3 = Array{ (int)v1, (int) v2, (int)v3 };
static_assert(std::is_same{}, ""); //
ok
static_assert(std::is_same{}, ""); //
ok
static_assert(std::is_same{}, ""); //
ok
for (auto c : array1) {} // ok
for (auto c : array2) {} // does not compile, says array2 has incomplete
type int[]
for (auto c : array3) {} // ok
}
void bar3(int a, int b, int c)
{
auto && array1 = Array{ 1, 2, 3 };
auto && array2 = Array{ a, b, c };
static_assert(std::is_same{}, ""); //
ok
static_assert(std::is_same{}, ""); //
ok
for (auto c : array1) {} // ok
for (auto c : array2) {} // ok
}
int main()
{
bar1(1, 2, 3);
bar2(1, 2, 3);
bar3(1, 2, 3);
}
--
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 44539] New: LIBGAV1 perf regression trunk vs. Clang 9
https://bugs.llvm.org/show_bug.cgi?id=44539 Bug ID: 44539 Summary: LIBGAV1 perf regression trunk vs. Clang 9 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com This is related to bug 44411. There is a significant perf regression in benchmark LIBGAV1. --- -O3 -march=znver1 Numbers are FPS (frames per second); more is better. ``` single thread -- 2000 frames | GCC 7.4 | CLANG 9.x | CLANG Master chimera_8b_1080p.ivf | 22.77 | 21.86 | 18.71 chimera_10b_1080p.ivf| 11.31 | 12.68 | 11.67 summer_nature_1080p.ivf | 21.10 | 21.02 | 18.29 summer_nature_4K.ivf | 4.74 | 4.57 | 3.94 multi threaded (8) -- no frame limit | GCC 7.4 | CLANG 9.x | CLANG master chimera_8b_1080p.ivf | 43.51 | 42.76 | 34.80 chimera_10b_1080p.ivf| 16.18 | 18.98 | 17.12 summer_nature_1080p.ivf | 64.22 | 63.66 | 53.89 summer_nature_4K.ivf | 17.57 | 17.17 | 14.70 multi threaded (16) -- no frame limit | GCC 7.4 | CLANG 9.x | CLANG master chimera_8b_1080p.ivf | 43.40 | 43.05 | 38.73 chimera_10b_1080p.ivf| 16.54 | 19.68 | 18.67 summer_nature_1080p.ivf | 62.72 | 62.20 | 54.96 summer_nature_4K.ivf | 19.31 | 19.11 | 17.13 ``` The single threaded execution is ~14% slower on master vs clang 9.x. Later I will post a full description of the underlying issue that caused this perf regression. tl;dr: performance degradation in libgav is caused by poor decisions made by pass "x86 cmov converter". In particular, a bunch of CMOVs from a hot loop are now sub-optimally expanded into if-then blocks. Those CMOVs weren't expanded by the Clang 9 compiler (that was the correct decision). If we disable that pass then we fully get back the performance loss. For example, decoding "chimera_8b_1080p.ivf" with a single thread gives us an average of 22.14 fps. As I wrote, I plan to post all my findings in a follow-up comment. NOTE: this is unlikely to be AMD specific. For example, I can reproduce the poor CMOV expansions if I generate code for Skylake. -- 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 44540] New: Inheriting from vector of move-only type leads to copy constructor being used
https://bugs.llvm.org/show_bug.cgi?id=44540
Bug ID: 44540
Summary: Inheriting from vector of move-only type leads to copy
constructor being used
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: we...@wsoptics.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following code does not compile with clang + libstdc++:
#include
struct MoveOnly
{
MoveOnly() = default;
MoveOnly(MoveOnly const &) = delete;
MoveOnly(MoveOnly &&) = default;
MoveOnly & operator=(MoveOnly const &) = delete;
MoveOnly & operator=(MoveOnly &&) = default;
};
template
class V : public std::vector
{
using std::vector::vector;
explicit V(std::vector const & v) : std::vector(v) {}
explicit V(std::vector && v) : std::vector(std::move(v)) {}
};
void f()
{
V v{};
}
It does however compile with gcc and also with clang + libc++. (But then again
not with MSVC.)
I think there's no reason for the copy constructor to be used here though.
See also
https://godbolt.org/z/m_G99y
--
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 44541] New: Instcombine hangs with "opt -functionattrs -disable-basicaa -O1"
https://bugs.llvm.org/show_bug.cgi?id=44541 Bug ID: 44541 Summary: Instcombine hangs with "opt -functionattrs -disable-basicaa -O1" Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 23015 --> https://bugs.llvm.org/attachment.cgi?id=23015&action=edit bbi-37458_x86.ll reproducer Running opt -functionattrs -disable-basicaa -O1 -S -o - ./bbi-37458_x86.ll seems to hang forever. Adding -debug-pass=Executions shows [2020-01-14 15:08:50.872376271] 0x611e690 Executing Pass 'Combine redundant instructions' on Function 'test_sub3_4'... and adding -debug gives repeated occurences of IC: Visiting: %_tmp2687 = select i1 %1808, i16 0, i16 %_tmp2685 IC: Visiting: %1808 = icmp sgt i16 0, %_tmp2685 IC: Mod = %1808 = icmp sgt i16 0, %_tmp2685 New = %1808 = icmp slt i16 %_tmp2682, 0 IC: ADD: %_tmp2687 = select i1 %1808, i16 0, i16 %_tmp2685 IC: ADD: %1808 = icmp slt i16 %_tmp2682, 0 IC: Visiting: %1808 = icmp slt i16 %_tmp2682, 0 IC: Visiting: %_tmp2687 = select i1 %1808, i16 0, i16 %_tmp2685 I've tried to reduce the command line to some minor variation of just opt -instcombine but I can't seem to manage that. :/ The problem seems to be fairly old, I've seen it in builds from around late March 2019. -- 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 44271] Assertion failure (Windows on Arm): assert((!RPI.isPaired() || !NeedsFrameRecord || RPI.Reg2 != AArch64::FP || RPI.Reg1 == AArch64::LR) && "FrameRecord mst be allocated togethe
https://bugs.llvm.org/show_bug.cgi?id=44271 Sanne Wouda changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||1cc8fff Resolution|--- |FIXED --- Comment #3 from Sanne Wouda --- Fixed by https://reviews.llvm.org/rG1cc8fff420a76ae869f73ce2b19e7c1fc73da3ed -- 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 44543] New: InstCombine should correctly propagate alignment
https://bugs.llvm.org/show_bug.cgi?id=44543
Bug ID: 44543
Summary: InstCombine should correctly propagate alignment
Product: libraries
Version: trunk
Hardware: PC
OS: All
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
Created attachment 23016
--> https://bugs.llvm.org/attachment.cgi?id=23016&action=edit
input.ll
```
$ cat input.ll
target datalayout = "p:64:64:64-i64:32:32"
define i64* @test1(i8* %x) {
entry:
%p = bitcast i8* %x to i64*
%b1 = load i64, i64* %p
%p2 = inttoptr i64 %b1 to i64*
ret i64* %p2
}
$ opt -instcombine input.ll -S -o -
target datalayout = "p:64:64:64-i64:32:32"
define i64* @test1(i8* %x) {
entry:
%0 = bitcast i8* %x to i64**
%b11 = load i64*, i64** %0, align 8
ret i64* %b11
}
```
The updated load should have align 4 because data layout says i64 has 4-bytes
alignment.
--
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 44544] New: Nested loop unroll bug on skylake avx512
https://bugs.llvm.org/show_bug.cgi?id=44544
Bug ID: 44544
Summary: Nested loop unroll bug on skylake avx512
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: jakobschw...@yahoo.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I think, I found a bug in clang, tested on local machines and on godbolt with
clang 7, 8 and 9. It only occurs with -O3 optimization and
-march=skylake-avx512. With GCC and Intel the code produces correct results.
Disabling loop nesting in the example is also fine with Clang. The code should
return just zeros in the cout print.
#include
int main(int argc, char *argv[])
{
static constexpr uint32_t mult = 4u;
static constexpr uint64_t MASK_H = 0xull;
uint64_t arr2[16][4];
for(auto i=0; i<16; i++) for(auto j=0; j<4; j++) arr2[i][j] = ~uint64_t(0);
uint64_t* mm =&arr2[0][0];
for(uint32_t zz=0; zz<16; zz++){
// #pragma clang loop unroll(disable)
for(uint32_t yy=0; yy<16; yy++){
const uint32_t ID = yy+zz*16;
const uint64_t mask = ~(MASK_H<<(ID%mult*16));
mm[ID/mult] &= mask;
}
}
for(auto i=0; i<16; i++) {
for(auto j=0; j<4; j++) std::cout << arr2[i][j] << " ";
std::cout << std::endl;
}
return 0;
}
--
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 44545] New: InstCombine does not simplify a "get first bit" kind of pattern due to no longer folding trunc over select
https://bugs.llvm.org/show_bug.cgi?id=44545
Bug ID: 44545
Summary: InstCombine does not simplify a "get first bit" kind
of pattern due to no longer folding trunc over select
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
Once upon-a-time, before this commit
commit e5bc4417913a3e606d572a5d661106612d3a99a7
Author: Sanjay Patel
Date: Thu May 31 00:16:58 2018 +
[InstCombine] don't change the size of a select if it would mismatch its
condition operands' sizes
Don't always:
cast (select (cmp x, y), z, C) --> select (cmp x, y), (cast z), C'
This is something that came up as far back as D26556, and I lost track of
it.
I suspect that this transform is part of the underlying problem that is
inspiring some of the recent proposals that seek to match larger patterns
that include a cast op. Even if that's not true, this transform causes
problems for codegen (particularly with vector types).
A transform to actively match the size of cmp and select operand sizes
should
follow. This patch just removes the harmful canonicalization in the other
direction.
Differential Revision: https://reviews.llvm.org/D47163
llvm-svn: 333611
the IR below was simplified by instcombine as
%t0 = call i32 @llvm.cttz.i32(i32 %data, i1 true)
%iszero = icmp eq i32 %data, 0
%0 = trunc i32 %t0 to i16
%sub = select i1 %iszero, i16 -1, i16 %0
ret i16 %sub
but nowadays instcombine doesn't simplify it at all.
;
; RUN: opt < %s -S -instcombine | FileCheck %s
declare i32 @llvm.cttz.i32(i32, i1)
define i16 @foo(i32 %data) {
entry:
%t0 = call i32 @llvm.cttz.i32(i32 %data, i1 true)
%t1 = add nuw nsw i32 %t0, 1
%iszero = icmp eq i32 %data, 0
%ffs = select i1 %iszero, i32 0, i32 %t1
%cast = trunc i32 %ffs to i16
%sub = add nsw i16 %cast, -1
ret i16 %sub
}
;
The patterns origins from a C function that count trailing zero bits in %data,
but returns -1 if the input is zero.
If I understand it correctly instcombine started to be more careful about
folding casts over select in case the condition origins from a cmp with same
bit width as the select operands. The idea was that lots of other combines
could trigger if not doing the rewrite.
No idea how to tackle this. In the example above it would have been good to do
the folding. Maybe there are lots of situations like this, when we'd benefit
from doing the fold.
--
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 18476 in oss-fuzz: llvm:clang-fuzzer: ASSERT: CodeDC && !CodeDC->isFileContext() && "statement expr not in code context"
Updates: Labels: Deadline-Approaching Comment #1 on issue 18476 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: CodeDC && !CodeDC->isFileContext() && "statement expr not in code context" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18476#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 18469 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions
Updates: Labels: Deadline-Approaching Comment #1 on issue 18469 by sheriff...@chromium.org: llvm:clang-fuzzer: Stack-overflow in AnalyzeImplicitConversions https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18469#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 44546] New: SEGV in DAGTypeLegalizer::AnalyzeNewNode
https://bugs.llvm.org/show_bug.cgi?id=44546 Bug ID: 44546 Summary: SEGV in DAGTypeLegalizer::AnalyzeNewNode Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: bjorn.a.petters...@ericsson.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 23017 --> https://bugs.llvm.org/attachment.cgi?id=23017&action=edit reduced reproducer Got a similar crash as the below for out out-of-tree target. After reducing the test case a bit I managed to reproduce something that seem to crash in a similar way (at least the stack trace is the same) for an in-tree target. One thing to notice is that there is a store <4 x i32> %t8, <4 x i32>* null in the input. But I still think it is unfortunate that we get a crash here. My debugging session for the out-of-tree target ended up somewhere around the ReplacedValues map. And it crashed for me if I add a Val.dump in DAGTypeLegalizer::AnalyzeNewValue after the call to RemapValue. Here is the stack trace: > llc -o - red3.ll -mtriple systemz .text .file "red3.ll" Stack dump: 0. Program arguments: build-all/bin/llc -o - red3.ll -mtriple systemz 1. Running pass 'Function Pass Manager' on module 'red3.ll'. 2. Running pass 'SystemZ DAG->DAG Pattern Instruction Selection' on function '@foo' #0 0x023fa194 PrintStackTraceSignalHandler(void*) (build-all/bin/llc+0x23fa194) #1 0x023f7d5e llvm::sys::RunSignalHandlers() (build-all/bin/llc+0x23f7d5e) #2 0x023fa59c SignalHandler(int) (build-all/bin/llc+0x23fa59c) #3 0x7fda6a92d630 __restore_rt (/lib64/libpthread.so.0+0xf630) #4 0x022bfdc6 llvm::DAGTypeLegalizer::AnalyzeNewNode(llvm::SDNode*) (build-all/bin/llc+0x22bfdc6) #5 0x022c23ed llvm::DAGTypeLegalizer::SetSplitVector(llvm::SDValue, llvm::SDValue, llvm::SDValue) (build-all/bin/llc+0x22c23ed) #6 0x022d8dea llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) (build-all/bin/llc+0x22d8dea) #7 0x022bf203 llvm::DAGTypeLegalizer::run() (build-all/bin/llc+0x22bf203) #8 0x022c4638 llvm::SelectionDAG::LegalizeTypes() (build-all/bin/llc+0x22c4638) #9 0x0225c238 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (build-all/bin/llc+0x225c238) #10 0x0225af91 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (build-all/bin/llc+0x225af91) #11 0x02257800 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x2257800) #12 0x01191352 (anonymous namespace)::SystemZDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build-all/bin/llc+0x1191352) #13 0x019c34a9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build-all/bin/llc+0x19c34a9) #14 0x01d57243 llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all/bin/llc+0x1d57243) #15 0x01d57528 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all/bin/llc+0x1d57528) #16 0x01d57b8d llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/llc+0x1d57b8d) #17 0x0079f4e5 compileModule(char**, llvm::LLVMContext&) (build-all/bin/llc+0x79f4e5) #18 0x0079cf5d main (build-all/bin/llc+0x79cf5d) #19 0x7fda69a24545 __libc_start_main (/lib64/libc.so.6+0x22545) #20 0x0079a8cf _start (build-all/bin/llc+0x79a8cf) Segmentation fault -- 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 44547] New: Inefficient codegen for remainder loop when vectorizing by factor of 2 (possibly more)
https://bugs.llvm.org/show_bug.cgi?id=44547
Bug ID: 44547
Summary: Inefficient codegen for remainder loop when
vectorizing by factor of 2 (possibly more)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: d.malju...@yandex.ru
CC: llvm-bugs@lists.llvm.org
See motivating example: https://godbolt.org/z/vSfTT9
void test(const int16_t* __restrict a, const int16_t* __restrict b, int16_t*
__restrict c, uint32_t n) {
#pragma nounroll
#pragma clang loop vectorize_width(2) interleave_count(1)
for (int32_t i = 0; i < n; i++) {
*c++ = *a++ + *b++;
}
}
One would imagine that the compiler would essentially turn this into
{
if (n & 1) *c++ = *a++ + *b++;
for (int32_t i = 0; i < n<<1; i++) {
...
}
}
But it generates something like this instead:
{
for (int32_t i = 0; i < n<<1; i++) {
...
}
if (n & 1) for (int32_t i = 0; i < phi(1, (n & 1)); i++) *c++ = *a++ +
*b++;
}
Loop vectorizer seems to always generate remainder "block", as a loop even if
it has known constant tripcount (in this case it's 1!).
However, since this tripcount is hidden behind an "if" (or switch condition
after some opts), this "remainder loop with tripcount == 1" is never really
unrolled (because SCEV fails to compute it's tripcount). Sometimes running
additional GVN and IPSCCP passes helps, but this is not optimal.
I don't see why remainder has to be a loop in the first place (when trip count
is known).
--
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 44543] InstCombine should correctly propagate alignment
https://bugs.llvm.org/show_bug.cgi?id=44543 Juneyoung Lee 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 44456] Assertion failure / segfault when internalizing twice-promoted global value
https://bugs.llvm.org/show_bug.cgi?id=44456 Teresa Johnson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Teresa Johnson --- Fix committed in 7dc4bbf8ab311606388faacca58b6c3e3e508b77. Unfortunately, I forgot to put the PR number in the description. -- 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 44245] [InstCombine] Infinite loop in a bitcode generated by rustc
https://bugs.llvm.org/show_bug.cgi?id=44245 Nikita Popov changed: What|Removed |Added Fixed By Commit(s)||65c0805be523445d7ad0f12e90f ||53648e1ae9f84 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Nikita Popov --- This got delayed a bit because the transform had additional problems, but the patch has landed 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 44549] New: [X86] uint64->f32 on 32-bit Windows without SSE can have double rounding
https://bugs.llvm.org/show_bug.cgi?id=44549 Bug ID: 44549 Summary: [X86] uint64->f32 on 32-bit Windows without SSE can have double rounding Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com On 32-bit targets without SSE we use the X87 unit to do uint64_t -> f32/f64/f80 conversions by converting a 64-bit integer into 80-bit extended precision using FILD. This is a signed conversion so then we add a fixup that is either 0 or 2^64 based on whether the original number was negative. Then we round the result if the destination type is f32 or f64. This should work correctly assuming the the PC field in X87's FPCW is set to 80-bit. The FILD is not subject to the PC field, but the fixup FADD is. On Windows, the PC field defaults to 64-bit. So the fixup FADD will round to the double precision. This means if we're doing a conversion from uint64_t to fp32, we'll round after the fixup FADD and round again when we do the fst to round to f32. Conversions to f64 should fine since we'll just round after the FADD and the final rounding operation won't do anything. -- 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 44550] New: Versioned Go paths are not valid
https://bugs.llvm.org/show_bug.cgi?id=44550 Bug ID: 44550 Summary: Versioned Go paths are not valid Product: Website Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: stephen.guteka...@gmail.com CC: llvm-bugs@lists.llvm.org, m...@sqlby.me According to the bindings/go/README.txt documentation: > The package path "llvm.org/llvm/bindings/go/llvm" can be used to > import the latest development version of LLVM from SVN. Paths such as > "llvm.org/llvm.v36/bindings/go/llvm" refer to released versions of LLVM. `llvm.org/llvm/bindings/go/llvm` does appear to be a valid Go package path as godoc.org is able to fetch the package contents for documentation generation: https://godoc.org/llvm.org/llvm/bindings/go/llvm But the versioned paths llvm.org/llvm.v36/bindings/go/llvm does not appear to be valid: https://godoc.org/llvm.org/llvm.v36/bindings/go/llvm This is an issue with the llvm.org website which is not responding correctly to the ?go-get=1 requests that are made. For example compare the `` tag output of: ```sh $ curl -L https://llvm.org/llvm/bindings/go/llvm?go-get=1 ... https://llvm.org/svn/llvm-project/llvm/trunk";> ... ``` vs: ```sh $ curl -L https://llvm.org/llvm.v36/bindings/go/llvm?go-get=1 ... 404 Not Found Not Found The requested URL /llvm.v36/bindings/go/llvm was not found on this server. Apache/2.4.7 (Ubuntu) Server at llvm.org Port 443 ``` -- 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 44551] New: Impossible to build Go and OCaml bindings on Windows using MSYS2
https://bugs.llvm.org/show_bug.cgi?id=44551 Bug ID: 44551 Summary: Impossible to build Go and OCaml bindings on Windows using MSYS2 Product: libraries Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: stephen.guteka...@gmail.com CC: llvm-bugs@lists.llvm.org It is currently impossible to build the Go and OCaml bindings on Windows natively under e.g. MSYS2 due to two issues in the build configuration/scripts: 1. [`build.sh`](https://github.com/llvm/llvm-project/blob/master/llvm/bindings/go/build.sh#L11) cannot handle quoted arguments, which prevents passing `-G "MSYS Makefiles"` to the script -- making it impossible to generate MSYS-compatible Makefiles. 2. In [`config-ix.cmake`](https://github.com/llvm/llvm-project/blob/master/llvm/cmake/config-ix.cmake#L546-L547) WIN32 (i.e. non-Cygwin environments like MSYS or native Windows) explicitly disables building the Go bindings without any way to attempt building them. I have a simple patch here which resolves the issue for Go (but I haven't tested OCaml, there could be other issues there). I have not yet had a chance to submit this via LLVM's patch submission process, but hope to do so soon: https://github.com/hexops/llvm-project/commit/3dd7f1a23d70c9e809fdda5b1d0f15175d6bfe8a?w=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
