[llvm-bugs] [Bug 31136] Cannot infer template argument
https://llvm.org/bugs/show_bug.cgi?id=31136 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Vassil Vassilev --- Works as designed, we should use submodules to remove this effect. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31690] New: Simple addition reduction not vectorised when limit is 48 or less.
https://llvm.org/bugs/show_bug.cgi?id=31690
Bug ID: 31690
Summary: Simple addition reduction not vectorised when limit is
48 or less.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: drr...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider this simple loop
float f(float x[]) {
float p = 1.0;
for (int i = 0; i < 48; i++)
p += x[i];
return p;
}
clang 3.9.1 gives
.LCPI0_0:
.long 1065353216 # float 1
f: # @f
vmovss xmm0, dword ptr [rdi] # xmm0 = mem[0],zero,zero,zero
vaddss xmm0, xmm0, dword ptr [rip + .LCPI0_0]
vaddss xmm0, xmm0, dword ptr [rdi + 4]
vaddss xmm0, xmm0, dword ptr [rdi + 8]
vaddss xmm0, xmm0, dword ptr [rdi + 12]
vaddss xmm0, xmm0, dword ptr [rdi + 16]
vaddss xmm0, xmm0, dword ptr [rdi + 20]
vaddss xmm0, xmm0, dword ptr [rdi + 24]
vaddss xmm0, xmm0, dword ptr [rdi + 28]
vaddss xmm0, xmm0, dword ptr [rdi + 32]
vaddss xmm0, xmm0, dword ptr [rdi + 36]
vaddss xmm0, xmm0, dword ptr [rdi + 40]
vaddss xmm0, xmm0, dword ptr [rdi + 44]
vaddss xmm0, xmm0, dword ptr [rdi + 48]
vaddss xmm0, xmm0, dword ptr [rdi + 52]
vaddss xmm0, xmm0, dword ptr [rdi + 56]
vaddss xmm0, xmm0, dword ptr [rdi + 60]
vaddss xmm0, xmm0, dword ptr [rdi + 64]
vaddss xmm0, xmm0, dword ptr [rdi + 68]
vaddss xmm0, xmm0, dword ptr [rdi + 72]
vaddss xmm0, xmm0, dword ptr [rdi + 76]
vaddss xmm0, xmm0, dword ptr [rdi + 80]
vaddss xmm0, xmm0, dword ptr [rdi + 84]
vaddss xmm0, xmm0, dword ptr [rdi + 88]
vaddss xmm0, xmm0, dword ptr [rdi + 92]
vaddss xmm0, xmm0, dword ptr [rdi + 96]
vaddss xmm0, xmm0, dword ptr [rdi + 100]
vaddss xmm0, xmm0, dword ptr [rdi + 104]
vaddss xmm0, xmm0, dword ptr [rdi + 108]
vaddss xmm0, xmm0, dword ptr [rdi + 112]
vaddss xmm0, xmm0, dword ptr [rdi + 116]
vaddss xmm0, xmm0, dword ptr [rdi + 120]
vaddss xmm0, xmm0, dword ptr [rdi + 124]
vaddss xmm0, xmm0, dword ptr [rdi + 128]
vaddss xmm0, xmm0, dword ptr [rdi + 132]
vaddss xmm0, xmm0, dword ptr [rdi + 136]
vaddss xmm0, xmm0, dword ptr [rdi + 140]
vaddss xmm0, xmm0, dword ptr [rdi + 144]
vaddss xmm0, xmm0, dword ptr [rdi + 148]
vaddss xmm0, xmm0, dword ptr [rdi + 152]
vaddss xmm0, xmm0, dword ptr [rdi + 156]
vaddss xmm0, xmm0, dword ptr [rdi + 160]
vaddss xmm0, xmm0, dword ptr [rdi + 164]
vaddss xmm0, xmm0, dword ptr [rdi + 168]
vaddss xmm0, xmm0, dword ptr [rdi + 172]
vaddss xmm0, xmm0, dword ptr [rdi + 176]
vaddss xmm0, xmm0, dword ptr [rdi + 180]
vaddss xmm0, xmm0, dword ptr [rdi + 184]
vaddss xmm0, xmm0, dword ptr [rdi + 188]
ret
This is fully unrolled but not vectorized.
However, using icc we get:
f:
movupsxmm13, XMMWORD PTR [rdi] #4.10
movupsxmm0, XMMWORD PTR [16+rdi]#4.10
movupsxmm6, XMMWORD PTR [32+rdi]#4.10
movupsxmm1, XMMWORD PTR [48+rdi]#4.10
movupsxmm9, XMMWORD PTR [64+rdi]#4.10
movupsxmm2, XMMWORD PTR [80+rdi]#4.10
movupsxmm7, XMMWORD PTR [96+rdi]#4.10
movupsxmm3, XMMWORD PTR [112+rdi] #4.10
movupsxmm10, XMMWORD PTR [128+rdi] #4.10
movupsxmm4, XMMWORD PTR [144+rdi] #4.10
movupsxmm8, XMMWORD PTR [160+rdi] #4.10
movupsxmm5, XMMWORD PTR [176+rdi] #4.10
addps xmm13, xmm0 #2.11
addps xmm6, xmm1#2.11
addps xmm9, xmm2#2.11
addps xmm7, xmm3#2.11
addps xmm10, xmm4 #2.11
addps xmm8, xmm5#2.11
addps xmm13, xmm6 #2.11
addps xmm9, xmm7#2.11
addps xmm10, xmm8 #2.11
addps xmm13, xmm9 #2.11
addps xmm13, xmm10 #2.11
movapsxmm11, xmm13
[llvm-bugs] [Bug 31691] New: Reporting of predicted benefits or vectorisation
https://llvm.org/bugs/show_bug.cgi?id=31691 Bug ID: 31691 Summary: Reporting of predicted benefits or vectorisation Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: drr...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When running the Intel Compiler with -qopt-report=4, say, you get told the expected performance gain from vectorisation, amongst other useful information. For example, LOOP BEGIN at permanent-in-c.c(47,7) remark #25045: Fused Loops: ( 47 50 ) remark #15388: vectorization support: reference v has aligned access [ permanent-in-c.c(48,2) ] remark #15388: vectorization support: reference v has aligned access [ permanent-in-c.c(48,2) ] remark #15389: vectorization support: reference M has unaligned access [ permanent-in-c.c(48,2) ] remark #15388: vectorization support: reference v has aligned access [ permanent-in-c.c(51,8) ] remark #15381: vectorization support: unaligned access used inside loop body remark #15305: vectorization support: vector length 4 remark #15399: vectorization support: unroll factor set to 2 remark #15309: vectorization support: normalized vectorization overhead 0.600 remark #15301: FUSED LOOP WAS VECTORIZED remark #15442: entire loop may be executed in remainder remark #15448: unmasked aligned unit stride loads: 1 remark #15449: unmasked aligned unit stride stores: 1 remark #15450: unmasked unaligned unit stride loads: 1 remark #15475: --- begin vector loop cost summary --- remark #15476: scalar loop cost: 49 remark #15477: vector loop cost: 10.000 remark #15478: estimated potential speedup: 4.580 remark #15487: type converts: 3 remark #15488: --- end vector loop cost summary --- remark #25456: Number of Array Refs Scalar Replaced In Loop: 2 LOOP END gcc also gives you similar if perhaps less useful information. [...] vect_model_reduction_cost: inside_cost = 6, prologue_cost = 2, epilogue_cost = 6 . test2.c:50:9: note: ==> examining statement: j_73 = j_186 + 1; test2.c:50:9: note: irrelevant. test2.c:50:9: note: ==> examining statement: if (j_73 < n.2_201) test2.c:50:9: note: irrelevant. test2.c:50:9: note: === vect_update_slp_costs_according_to_vf === test2.c:50:9: note: cost model: epilogue peel iters set to vf/2 because loop iterations are unknown . test2.c:50:9: note: Cost model analysis: Vector inside of loop cost: 50 Vector prologue cost: 8 Vector epilogue cost: 52 Scalar iteration cost: 20 Scalar outside cost: 4 Vector outside cost: 60 prologue iterations: 0 epilogue iterations: 2 Calculated minimum iters for profitability: 5 test2.c:50:9: note: Runtime profitability threshold = 4 test2.c:50:9: note: Static estimate profitability threshold = 4 test2.c:50:9: note: epilog loop required [...] It would be great if clang/llvm could provide similar information to the user/coder. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31692] New: After r291388: Assertion failed: (it != OpaqueRValues.end() && "no mapping for opaque value!"), function getOpaqueRValueMapping, file tools/clang/lib/CodeGen/CodeGenFuncti
https://llvm.org/bugs/show_bug.cgi?id=31692
Bug ID: 31692
Summary: After r291388: Assertion failed: (it !=
OpaqueRValues.end() && "no mapping for opaque
value!"), function getOpaqueRValueMapping, file
tools/clang/lib/CodeGen/CodeGenFunction.h, line 2008.
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
After r291388 (bug 23135: Don't instantiate constexpr functions referenced in
unevaluated operands where possible), bootstrapping clang with clang itself
results in an assertion while compiling lib/MC/MCParser/AsmParser.cpp:
Assertion failed: (it != OpaqueRValues.end() && "no mapping for opaque
value!"), function getOpaqueRValueMapping, file
tools/clang/lib/CodeGen/CodeGenFunction.h, line 2008.
Abort trap
Minimized test case:
// clang -cc1 -triple x86_64 -S -std=c++11 testcase.cpp
template struct x0;
template struct x1 { static int x2; };
template struct x4 : x1<__is_constructible(x3)> {};
template struct x5;
template struct x6 {
template ::x2...>::x2>::x8> x6();
};
template struct x10 : x9 {};
struct x11 {
struct x12 {
int x13 = 0;
} x14;
x10> x15;
void x16();
};
void x11::x16() {
if (x14.x13)
;
}
Bisection shows this assertion to have been introduced by r291388.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31693] New: Failure to recognise some integer MIN/MAX CLAMP patterns
https://llvm.org/bugs/show_bug.cgi?id=31693
Bug ID: 31693
Summary: Failure to recognise some integer MIN/MAX CLAMP
patterns
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: fil...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
Classification: Unclassified
Value clamping is often implemented using either of these patterns:
#define MIN(v,a) ((v) < (a) ? (v) : (a))
#define MAX(v,a) ((v) < (a) ? (a) : (v))
#define CLAMP(v,l,h) MIN(MAX((v),(l)),(h))
//#define CLAMP(v,l,h) ((v) < (l) ? (l) : ((v) > (h) ? (h) : (v)))
void clamp_v4u32(unsigned int *a) {
for (int i = 0; i != 4; ++i, ++a) {
unsigned int v = *a;
v = CLAMP(v, 15, 255);
*a = v;
}
}
The first implementation nicely lowers to a pair of UMIN/UMAX instructions:
llc -mcpu=btver2 -mtriple=x86_64-unknown
define void @clamp_v4u32((i32* nocapture) {
%2 = bitcast i32* %0 to <4 x i32>*
%3 = load <4 x i32>, <4 x i32>* %2, align 4
%4 = icmp ugt <4 x i32> %3,
%5 = select <4 x i1> %4, <4 x i32> %3, <4 x i32>
%6 = icmp ult <4 x i32> %5,
%7 = select <4 x i1> %6, <4 x i32> %5, <4 x i32>
%8 = bitcast i32* %0 to <4 x i32>*
store <4 x i32> %7, <4 x i32>* %8, align 4
ret void
}
clamp_v4u32:
vmovdqu (%rdi), %xmm0
vpmaxud .LCPI0_0(%rip), %xmm0, %xmm0
vpminud .LCPI0_1(%rip), %xmm0, %xmm0
vmovdqu %xmm0, (%rdi)
retq
The second struggles fails to recognise that we can safely combine the second
comparison under certain circumstances:
define void @clamp_v4u32(i32* nocapture) {
%2 = bitcast i32* %0 to <4 x i32>*
%3 = load <4 x i32>, <4 x i32>* %2, align 4
%4 = icmp ult <4 x i32> %3,
%5 = icmp ult <4 x i32> %3,
%6 = select <4 x i1> %5, <4 x i32> %3, <4 x i32>
%7 = select <4 x i1> %4, <4 x i32> , <4 x
i32> %6
%8 = bitcast i32* %0 to <4 x i32>*
store <4 x i32> %7, <4 x i32>* %8, align 4
ret void
}
clamp_v4u32:
vmovdqu (%rdi), %xmm0
vmovdqa .LCPI0_1(%rip), %xmm2 # xmm2 =
[2147483663,2147483663,2147483663,2147483663]
vpxor .LCPI0_0(%rip), %xmm0, %xmm1
vpminud .LCPI0_3(%rip), %xmm0, %xmm0
vpcmpgtd%xmm1, %xmm2, %xmm1
vblendvps %xmm1, .LCPI0_2(%rip), %xmm0, %xmm0
vmovups %xmm0, (%rdi)
retq
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31694] New: Clang does not define the macros related to SVR-4 abicalls
https://llvm.org/bugs/show_bug.cgi?id=31694 Bug ID: 31694 Summary: Clang does not define the macros related to SVR-4 abicalls Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Clang currently does not define __ABICALLS__ for NetBSD or for FreeBSD. Additionally, the target independant macro __mips_abicalls is not defined for all mips targets. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28181] ICE on invalid code on x86_64-linux-gnu (Assertion `isa(Val) && "cast() argument of incompatible type!"' failed, clang::Sema::AddBuiltinOperatorCandidates)
https://llvm.org/bugs/show_bug.cgi?id=28181 Alex Lorenz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alex Lorenz --- Fixed in r292497 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31695] New: Export attribute on inline template method not ignored
https://llvm.org/bugs/show_bug.cgi?id=31695
Bug ID: 31695
Summary: Export attribute on inline template method not ignored
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given a header
#ifdef BUILDING_LIB
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif
namespace MyNS {
EXPORT void func();
template
EXPORT inline int someFunc(int input = size);
}
template
int MyNS::someFunc(int input)
{
return input * 2;
}
and trivial source file:
#include "export-inline.h"
namespace MyNS {
void func()
{
}
}
and consumer:
#include "export-inline.h"
int main()
{
MyNS::func();
int sf = MyNS::someFunc(43);
return 0;
}
and buildsystem:
add_library(sh SHARED
export-inline.cpp
)
target_compile_definitions(sh PRIVATE BUILDING_LIB)
add_executable(shconsumer export-consumer.cpp)
target_link_libraries(shconsumer sh)
clang-cl fails to ignore the export attribute and the link fails.
unresolved external symbol "__declspec(dllimport) int __cdecl
MyNS::someFunc<3>(int)" (__imp_??$someFunc@$02@MyNS@@YAHH@Z) referenced in
function main
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 13403] Clang does not properly resolve classname::classname as constructor
https://llvm.org/bugs/show_bug.cgi?id=13403 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |FIXED --- Comment #5 from Richard Smith --- Fixed for Clang 5 in r292518. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31697] New: Bitcasts block copy forwarding
https://llvm.org/bugs/show_bug.cgi?id=31697
Bug ID: 31697
Summary: Bitcasts block copy forwarding
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: arc...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
If you have a situation where memory pointed to by a readonly argument %x is
copied to a local alloca %y and then %y is projected from, then LLVM normally
eliminates the unnecessary copy. This IR:
declare void @llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
declare void @llvm.lifetime.start(i64, i8*)
declare void @llvm.lifetime.end(i64, i8*)
define i32 @copy_then_extract({ i32,i32,i32,i32 }* noalias nocapture readonly
dereferenceable(16) %x, i32 %n) {
entry:
%y = alloca { i32, i32, i32, i32 }, align 16
%x0p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 0
%x0 = load i32, i32* %x0p
%x1p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 1
%x1 = load i32, i32* %x1p
%x2p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 2
%x2 = load i32, i32* %x2p
%x3p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 3
%x3 = load i32, i32* %x3p
%yi8 = bitcast { i32, i32, i32, i32 }* %y to i8*
call void @llvm.lifetime.start(i64 16, i8* %yi8)
%y0p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 0
store i32 %x0, i32* %y0p
%y1p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 1
store i32 %x1, i32* %y1p
%y2p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 2
store i32 %x2, i32* %y2p
%y3p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 3
store i32 %x3, i32* %y3p
%ya = bitcast i8* %yi8 to i32*
%ya2p = getelementptr inbounds i32, i32* %ya, i64 2
%y2 = load i32, i32* %ya2p
%yi8_2 = bitcast { i32, i32, i32, i32 }* %y to i8*
call void @llvm.lifetime.end(i64 16, i8* %yi8_2)
ret i32 %y2
}
reduces to:
define i32 @copy_then_extract({ i32, i32, i32, i32 }* noalias nocapture
readonly dereferenceable(16) %x, i32 %n) local_unnamed_addr #0 {
entry:
%x2p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i64 0, i32 2
%x2 = load i32, i32* %x2p, align 4
ret i32 %x2
}
However, if %ya2p becomes a dynamic GEP by changing `i64 2` to `i64 %n`, then
the bitcast can no longer be reduced since that's not valid against a struct.
This ends up completely blocking copy forwarding. This IR:
declare void @llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
declare void @llvm.lifetime.start(i64, i8*)
declare void @llvm.lifetime.end(i64, i8*)
define i32 @copy_then_extract({ i32,i32,i32,i32 }* noalias nocapture readonly
dereferenceable(16) %x, i32 %n) {
entry:
%y = alloca { i32, i32, i32, i32 }, align 16
%x0p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 0
%x0 = load i32, i32* %x0p
%x1p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 1
%x1 = load i32, i32* %x1p
%x2p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 2
%x2 = load i32, i32* %x2p
%x3p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%x, i32 0, i32 3
%x3 = load i32, i32* %x3p
%yi8 = bitcast { i32, i32, i32, i32 }* %y to i8*
call void @llvm.lifetime.start(i64 16, i8* %yi8)
%y0p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 0
store i32 %x0, i32* %y0p
%y1p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 1
store i32 %x1, i32* %y1p
%y2p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 2
store i32 %x2, i32* %y2p
%y3p = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }*
%y, i32 0, i32 3
store i32 %x3, i32* %y3p
%ya = bitcast i8* %yi8 to i32*
%ya2p = getelementptr inbounds i32, i32* %ya, i32 %n
%y2 = load i32, i32* %ya2p
%yi8_2 = bitcast { i32, i32, i32, i32 }* %y to i8*
call void @llvm.lifetime.end(i64 16, i8* %yi8_2)
ret i32 %y2
}
still keeps the unnecessary copy in the optimized IR:
define i32 @copy_then_extract({ i32, i32, i32, i32 }* noalias nocapture
readonly dereferenceable(16) %x, i32 %n) local_unnamed_addr #1 {
entry:
%y = alloca <4 x i32>, align 16
%0 = bitcast { i32, i32, i32, i32 }* %x to <4 x i32>*
%1 = load <4 x i32>, <4 x i32>* %0, align 4
%yi8 = bitcast <4 x i32>* %y to i8*
call void @llvm.lifetime.start(i64 16, i8* %yi8)
store <4 x i32> %1, <4 x i32>* %y, align
[llvm-bugs] [Bug 31696] New: inlinable function call in a function with debug info must have a !dbg location
https://llvm.org/bugs/show_bug.cgi?id=31696 Bug ID: 31696 Summary: inlinable function call in a function with debug info must have a !dbg location Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ttaub...@mozilla.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified inlinable function call in a function with debug info must have a !dbg location call void @__sanitizer_cov_trace_cmp8(i64 %index.next.1, i64 %n.vec) inlinable function call in a function with debug info must have a !dbg location call void @__sanitizer_cov_trace_pc_guard(i32* inttoptr (i64 add (i64 ptrtoint ([12 x i32]* @__sancov_gen_.49 to i64), i64 32) to i32*)) inlinable function call in a function with debug info must have a !dbg location call void @__sanitizer_cov_trace_cmp8(i64 %52, i64 %n.vec) fatal error: error in backend: Broken function found, compilation aborted! clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 4.0.0 (trunk 289944) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/worker/third_party/llvm-build/Release+Asserts/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/FuzzerTracePC-0658ac.cpp clang: note: diagnostic msg: /tmp/FuzzerTracePC-0658ac.sh clang: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31698] New: NewGVN fails to do store to load forwarding
https://llvm.org/bugs/show_bug.cgi?id=31698 Bug ID: 31698 Summary: NewGVN fails to do store to load forwarding Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: bigchees...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17868 --> https://llvm.org/bugs/attachment.cgi?id=17868&action=edit IR For the attached code, opt -gvn optimizes to one load and one store. -newgvn optimizes to two loads and one store. It fails to do the store to load forwarding. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31699] New: [Windows] LLDB crashes when launched with a startup script on the command line.
https://llvm.org/bugs/show_bug.cgi?id=31699 Bug ID: 31699 Summary: [Windows] LLDB crashes when launched with a startup script on the command line. Product: lldb Version: 4.0 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: vadi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified - Install LLVM for Windows snapshot build from http://llvm.org/build (SVN r291454, built on 9 January 2017 at the time of filing this). - Launch LLDB: lldb -O "p 42". - LLDB crashes. I've tracked the cause down to snapshot builds being built with a statically linked CRT (-DLLVM_USE_CRT_RELEASE=MT). When a startup script is given on the command line, lldb.exe creates a pipe, writes the script into the write end, wraps a stdio file around the read end, and gives the resulting FILE* to SBDebugger::SetInputFileHandle(). Unfortunately, since SBDebugger lives in liblldb.dll, with its own copy of the CRT, that handle is not valid there. Later, it tries to read from that handle, and... boom. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31700] New: always_inline is stronger than sanitize/no_sanitize mismatch
https://llvm.org/bugs/show_bug.cgi?id=31700
Bug ID: 31700
Summary: always_inline is stronger than sanitize/no_sanitize
mismatch
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Inlining is disabled for functions with different sets of no_sanitize
attributes, because that could lead to either over- or under-sanitizing the
code, and it not clear which is better in general (and sometimes both are
wrong).
Apparently, always_inline attribute is stronger than that.
In the following example, f is inlined into g when build with -O3
-fsanitize=memory.
int sink;
__attribute__((always_inline, no_sanitize("memory")))
void f() {
sink = 1;
}
void g() {
f();
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31701] New: ICE when initializing a const class with a class static variable template
https://llvm.org/bugs/show_bug.cgi?id=31701
Bug ID: 31701
Summary: ICE when initializing a const class with a class
static variable template
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: charles...@playstation.sony.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
We encountered an assertion failure when compiling a test-case with class
static template variables that contains an error. The crash happens after
an appropriate error message is produced.
This ICE started on revision 245497
$ svn log -r 245497
r245497 | rsmith | 2015-08-19 13:49:38 -0700 (Wed, 19 Aug 2015) | 2 lines
Internal-linkage variables with constant-evaluatable initializers do not need
to be emitted.
(Also reduces the set of variables that need to be eagerly deserialized when
using PCH / modules.)
Here is the test case.
$ cat t.cpp
class C {
template static int n;
};
template class D;
template
template void D::set() {
const C c = C::n;
}
Here is the ICE message:
$ clang t.cpp -c
t.cpp:2:32: warning: variable templates are a C++14 extension
[-Wc++14-extensions]
template static int n;
^
t.cpp:6:28: error: out-of-line definition of 'set' from class 'D' without
definition
template void D::set() {
~~^
clang-4.0: /home/chli/Source/usvn/llvm/tools/clang/lib/AST/Decl.cpp:2164:
clang::APValue*
clang::VarDecl::evaluateValue(llvm::SmallVectorImpl >&) const: Assertion `!Init->isValueDependent()'
failed.
clang-4.0: error: unable to execute command: Aborted (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 5.0.0 (trunk 292529)
Target: x86_64-unknown-linux-gnu
Thread model: posix
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31701] ICE when initializing a const class with a class static variable template
https://llvm.org/bugs/show_bug.cgi?id=31701 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Fixed in r292561. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31702] New: Misc incorrect folds with fabs
https://llvm.org/bugs/show_bug.cgi?id=31702
Bug ID: 31702
Summary: Misc incorrect folds with fabs
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: justin.le...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.arsena...@amd.com
Classification: Unclassified
Testcase (opt -instcombine):
define double @f1(double %x) local_unnamed_addr #0 {
entry:
%call = tail call double @llvm.fabs.f64(double %x)
%add = fadd double %call, 0x7FF8
%abs = tail call double @llvm.fabs.f64(double %add)
ret double %abs
}
define double @f2(double %x) local_unnamed_addr #1 {
entry:
%call1 = tail call double @llvm.maxnum.f64(double 0x7FF8, double
%x)
%call2 = tail call double @llvm.fabs.f64(double %call1)
ret double %call1
}
define double @f3(double %x, i32 %n) local_unnamed_addr #1 {
entry:
%call1 = tail call double @llvm.powi.f64(double -0.0, i32 %n)
%call2 = tail call double @llvm.fabs.f64(double %call1)
ret double %call1
}
declare double @llvm.maxnum.f64(double, double)
declare double @llvm.fabs.f64(double)
declare double @llvm.powi.f64(double, i32)
instcombine eliminates fabs calls from all of these, so the sign bit could be
wrong. I think a few others are wrong too.
See https://reviews.llvm.org/D28927.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31448] libc++ fails to compile on systems without posix_memalign
https://llvm.org/bugs/show_bug.cgi?id=31448 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Eric Fiselier --- Fixed in r292564 and merged into the 4.0 release branch. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30995] [META][GVN] NewGVN Integration
https://llvm.org/bugs/show_bug.cgi?id=30995 Bug 30995 depends on bug 31682, which changed state. Bug 31682 Summary: NewGVN asserts "new class for instruction should not be dominated by instruction" https://llvm.org/bugs/show_bug.cgi?id=31682 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31682] NewGVN asserts "new class for instruction should not be dominated by instruction"
https://llvm.org/bugs/show_bug.cgi?id=31682 Daniel Berlin 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
