[llvm-bugs] [Bug 29002] [x86] extra cmov in clamp function
https://llvm.org/bugs/show_bug.cgi?id=29002 AsafBadouh changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from AsafBadouh --- fix in revision 286938 -- 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 30984] [ELF] - Relocatable output incorrectly handles __tls_get_addr
https://llvm.org/bugs/show_bug.cgi?id=30984 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r286941 -- 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 31020] New: Attributed K&R function definition doesn't merge with a prototyped declaration
https://llvm.org/bugs/show_bug.cgi?id=31020 Bug ID: 31020 Summary: Attributed K&R function definition doesn't merge with a prototyped declaration Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: eugvelesev...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17590 --> https://llvm.org/bugs/attachment.cgi?id=17590&action=edit test Look at the test: _Bool K&R parameter is promoted to int but clang considers the K&R function as prototyped one because of the attribute. SemaDecl.cpp CreateNewFunctionDecl: bool HasPrototype = (D.isFunctionDeclarator() && D.getFunctionTypeInfo().hasPrototype) || (!isa(R.getTypePtr()) && R->isFunctionProtoType()); So isa(R.getTypePtr()) is false because R.getTypePtr() is AttributedType. -- 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 31019] New: Tonga Bad rendering since AMDGPU: Implement SGPR spilling with scalar stores
https://llvm.org/bugs/show_bug.cgi?id=31019 Bug ID: 31019 Summary: Tonga Bad rendering since AMDGPU: Implement SGPR spilling with scalar stores Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: adf.li...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17589 --> https://llvm.org/bugs/attachment.cgi?id=17589&action=edit valley bad shaders bz2 R9285 VI TONGA getting a screen full of colours with unigine valley (extremehd preset) since below. Unreal elemental also affected. commit 4404d0d6e354e80dd7f8f0a0e12d8ad809cf007e Author: Matt Arsenault Date: Sun Nov 13 18:20:54 2016 + AMDGPU: Implement SGPR spilling with scalar stores nThis avoids the nasty problems caused by using memory instructions that read the exec mask while spilling / restoring registers used for control flow masking, but only for VI when these were added. This always uses the scalar stores when enabled currently, but it may be better to still try to spill to a VGPR and use this on the fallback memory path. The cache also needs to be flushed before wave termination if a scalar store is used. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286766 91177308-0d34-0410-b5e6-96231b3b80d8 -- 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 31021] New: 1 << 63 not accepted for 64-bit enum value
https://llvm.org/bugs/show_bug.cgi?id=31021
Bug ID: 31021
Summary: 1 << 63 not accepted for 64-bit enum value
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: avasi...@gmx.net
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code does not compile under any clang version, but compiles on
gcc and MSVC:
enum: long long { test = 1 << 63};
int 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 31021] 1 << 63 not accepted for 64-bit enum value
https://llvm.org/bugs/show_bug.cgi?id=31021 Alexander Vassilev 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
[llvm-bugs] [Bug 31022] New: No packages for Ubuntu 16.10
https://llvm.org/bugs/show_bug.cgi?id=31022 Bug ID: 31022 Summary: No packages for Ubuntu 16.10 Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: clap...@yandex.ru CC: llvm-bugs@lists.llvm.org Classification: Unclassified Please, add. Many thanks for your work! -- 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 31023] New: Merge r276347 to 3.9.1
https://llvm.org/bugs/show_bug.cgi?id=31023 Bug ID: 31023 Summary: Merge r276347 to 3.9.1 Product: new-bugs Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: guy.bl...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified [X86] Do not use AND8ri8 in AVX512 pattern This variant is (as documented in the TD) for disassembler use only, and should not be used in patterns - it is longer, and is broken on 64-bit. Without this change, illegal instructions could be generated. -- 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 30981] AVX512: FastISel generates invalid seto
https://llvm.org/bugs/show_bug.cgi?id=30981 Zvi Rackover changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Zvi Rackover --- Fixed in r286958 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30851, which changed state. Bug 30851 Summary: Merge r283223 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30851 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 30851] Merge r283223 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30851 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Alexey Bataev --- Committed: rL286964 Merging r284110: rL286965 Merging r286129: rL286966 Merging r286584: rL286968 Merging r286944: rL286970 Merging r284229: rL286972 Merging r283223: -- 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 31024] New: [X86] Unnecessary register moves
https://llvm.org/bugs/show_bug.cgi?id=31024
Bug ID: 31024
Summary: [X86] Unnecessary register moves
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define <8 x i64> @sext_16i8_to_8i64(<16 x i8> %A) nounwind uwtable readnone ssp
{
entry:
%B = shufflevector <16 x i8> %A, <16 x i8> undef, <8 x i32>
%C = sext <8 x i8> %B to <8 x i64>
ret <8 x i64> %C
}
llc -mtriple=x86_64-unknown-unknown -mattr=+avx2
sext_16i8_to_8i64:
vpmovsxbq %xmm0, %ymm2
vpshufd {{.*#+}} xmm0 = xmm0[1,1,2,3]
vpmovsxbq %xmm0, %ymm1
vmovdqa %ymm2, %ymm0
retq
This could avoid the register move:
sext_16i8_to_8i64:
vpshufd {{.*#+}} xmm1 = xmm0[1,1,2,3]
vpmovsxbq %xmm0, %ymm0
vpmovsxbq %xmm1, %ymm1
retq
Reg-reg moves are almost free but its still better to avoid them if we can.
--
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 30608] Super slow to compile simple code (Loop Invariant Code Motion, 3.8: 0.05s, 3.9: 1m+. >1200% slowdown)
https://llvm.org/bugs/show_bug.cgi?id=30608 Alexandre Bique changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #19 from Alexandre Bique --- Hi, I did build the branch 3.9 this morning, and it is slow to build. I believe that the fix was not grafted onto the 3.9 branch? Many thanks, Alex -- 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 31021] 1 << 63 not accepted for 64-bit enum value
https://llvm.org/bugs/show_bug.cgi?id=31021 Richard Smith changed: What|Removed |Added CC||richard-l...@metafoo.co.uk Resolution|FIXED |INVALID -- 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 13248] efficient implementation of sitofp for vectors
https://llvm.org/bugs/show_bug.cgi?id=13248 Simon Pilgrim changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Fixed in rL286979 -- 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 31025] New: deleted move constructor ignored by return statement
https://llvm.org/bugs/show_bug.cgi?id=31025
Bug ID: 31025
Summary: deleted move constructor ignored by return statement
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: cubbi...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
When returning a class lvalue with deleted move constructor, first phase of the
return statement's overload resolution selects that deleted move constructor
and results in an error in GCC, Intel, and MSVC. Clang, however, silently falls
through to the second phase overload resolution (and selects the copy ctor if
available):
struct B
{
B() {};
B(const B &) {};
B(B &&) = delete;
};
B bar() {
B b;
return b; // OK in Clang, Error in GCC, Intel, MSVC
}
The relevant standardese is [class.copy]/32 "If the first overload resolution
fails ... " and it appears clang disagrees with others w.r.t. what it means for
overload resolution to "fail" in this context.
--
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 31026] New: Merge r286998 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=31026 Bug ID: 31026 Summary: Merge r286998 into the 3.9 branch Product: libraries Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: chf...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This fixes the runtime results produces by the fallback multiplication expansion introduced in r270720. -- 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 31017] ccc-analyzer is NO sufficient to build glibc
https://llvm.org/bugs/show_bug.cgi?id=31017 Devin Coughlin changed: What|Removed |Added Status|RESOLVED|REOPENED CC||dcough...@apple.com Resolution|INVALID |--- --- Comment #2 from Devin Coughlin --- It looks like this is happening because the configure script requires GCC 4.7+ and clang only claims to be compatible (via the preprocessor defines in InitPreprocessor.cpp) with GCC 4.2.1. I wonder if we can bump the claimed compatibility? -- 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 31027] New: thinlto link failure
https://llvm.org/bugs/show_bug.cgi?id=31027 Bug ID: 31027 Summary: thinlto link failure Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: parag.warud...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Trying to build ZeroC ICE (https://zeroc.com/distributions/ice#source) on Ubuntu 14.04 using clang++-3.9. /usr/bin/ld is symlinked to /usr/bin/ld.gold. The build fails in /cpp/src/slice2cs directory if -flto=thin is used. clang++-3.9 -rdynamic -m64 -flto=thin -fvisibility=hidden -Wall -Werror -pthread -fPIC -g -L../../lib/x86_64-linux-gnu -Wl,--disable-new-dtags -Wl,-rpath,\$ORIGIN/../lib/x86_64-linux-gnu -o ../../bin/slice2cs Gen.o Main.o -lSlice -lIceUtil Gen.cpp:2996: error: undefined reference to 'Slice::Gen::TieVisitor::TieVisitor(IceUtilInternal::Output&)' Gen.cpp:3003: error: undefined reference to 'Slice::Gen::ImplVisitor::ImplVisitor(IceUtilInternal::Output&)' Gen.cpp:3010: error: undefined reference to 'Slice::Gen::ImplTieVisitor::ImplTieVisitor(IceUtilInternal::Output&)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Replacing the -flto=thin with just -flto and keeping the same rest of the command line the link succeeds. I am not sure however since normal LTO succeeds, it looks like this is a bug with ThinLTO? [ If anyone wants to reproduce this, ICE is easy to build with few dependencies -mcpp, libssl-dev etc- and requires passing CXX=clang++-3.9 to make along with modifying the Make.rules.Linux to treat clang++-3.9 as g++ and adding -flto=thin to CXXFLAGS.] -- 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 31028] New: Too much division
https://llvm.org/bugs/show_bug.cgi?id=31028
Bug ID: 31028
Summary: Too much division
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: fil...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Mentioned by Tillmann Karras.
The x86 backend emits too many idiv instructions for this function:
#include
int32_t f(int32_t a, int32_t b) {
if (a % b == 42)
return a / b;
return 3;
}
Codegen:
x86-64 (annotated):
patatino(int, int): # @patatino(int, int)
mov ecx, edi
mov eax, ecx
cdq
idivesi # This gets us quotient in rax, remainder in rdx
mov eax, 3
cmp edx, 42
jne .LBB0_2
mov eax, ecx
cdq
idivesi # This is useless since we already had the result
before
.LBB0_2:
ret
arm64 target (Only one divide. Different trick ("multiply-subtract"
instruction: msub)):
patatino(int, int): // @patatino(int, int)
mov w8, w0
sdivw0, w8, w1
msubw8, w0, w1, w8
cmp w8, #42 // =42
b.eq.LBB0_2
orr w0, wzr, #0x3
.LBB0_2:
ret
--
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 31029] New: inlinable function call in a function with debug info must have a !dbg location
https://llvm.org/bugs/show_bug.cgi?id=31029
Bug ID: 31029
Summary: inlinable function call in a function with debug info
must have a !dbg location
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org, r...@google.com
Classification: Unclassified
a.ii:
class __declspec(dllexport) A {
A(int * = new int) {}
};
$ clang -cc1 -triple i386-pc-windows-msvc19.0.0 -emit-obj
-debug-info-kind=line-tables-only -fms-extensions a.ii
inlinable function call in a function with debug info must have a !dbg location
%call2 = call x86_thiscallcc %class.A* @"\01??0A@@AAE@PAH@Z"(%class.A*
%this1, i32* %0)
fatal error: error in backend: Broken function found, compilation aborted!
I'm currently bisecting.
--
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 23281] clang allows invalid code with lambda expression move-assignment
https://llvm.org/bugs/show_bug.cgi?id=23281 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Fixed in r287057. -- 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 31030] New: leak in __cxa_demangle
https://llvm.org/bugs/show_bug.cgi?id=31030
Bug ID: 31030
Summary: leak in __cxa_demangle
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: k...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
on fresh trunk: feed these 8 bytes into __cxa_demangle to get a memory leak:
: 5f5a 355a 835a 8340 _Z5Z.Z.@
full reproducer:
#include
extern "C" char *
__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
int main() {
unsigned char buf[] = {0x5f, 0x5a, 0x35, 0x5a, 0x83, 0x5a, 0x83, 0x40, 0};
__cxa_demangle((char*)buf, 0, 0, 0);
}
cc llvm/projects/libcxxabi/src
clang++ -std=c++11 -g cxa_demangle.cpp -I../include repro.cc -o repro
-fsanitize=address
==20050==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x4c1fce in realloc
#1 0x4f0c33 in __cxa_demangle
llvm/projects/libcxxabi/src/cxa_demangle.cpp:5023:47
(found by libFuzzer, see also
https://bugs.chromium.org/p/chromium/issues/detail?id=606626)
--
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 31031] New: __cxa_demangle consumes 6.5Gb on "___Z2i_D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D"
https://llvm.org/bugs/show_bug.cgi?id=31031
Bug ID: 31031
Summary: __cxa_demangle consumes 6.5Gb on
"___Z2i_D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1
D1D1D1D1D1D1D"
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: k...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Feed "___Z2i_D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D"
into __cxa_demangle and watch it consume 6.5 Gb of RAM:
#include
extern "C" char *
__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
int main() {
__cxa_demangle("___Z2i_D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D",
0, 0, 0);
}
clang++ -std=c++11 -g cxa_demangle.cpp -I../include repro.cc -o repro
/usr/bin/time ./repro
8.55user 2.41system 0:10.98elapsed 99%CPU (0avgtext+0avgdata
6557996maxresident)k
(found by libFuzzer, see also
https://bugs.chromium.org/p/chromium/issues/detail?id=606626)
--
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 30915] Move from ErrorOr to Expected in llvm/Object/ELF.h
https://llvm.org/bugs/show_bug.cgi?id=30915 Davide Italiano changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Davide Italiano --- Finally done with it. r287082 (and r287083 for lld) -- 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 30540] Fuzzing lld/ELF
https://llvm.org/bugs/show_bug.cgi?id=30540 Bug 30540 depends on bug 30915, which changed state. Bug 30915 Summary: Move from ErrorOr to Expected in llvm/Object/ELF.h https://llvm.org/bugs/show_bug.cgi?id=30915 What|Removed |Added Status|ASSIGNED|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 31032] New: [X86] Extra scalar move in scalar intrinsic sequences
https://llvm.org/bugs/show_bug.cgi?id=31032
Bug ID: 31032
Summary: [X86] Extra scalar move in scalar intrinsic sequences
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This IR sequence produces an extra move or blend of zero into the upper bits
just before the minss instruction.
; Function Attrs: nounwind
define i16 @test1(float %f) #0 {
%tmp = insertelement <4 x float> undef, float %f, i32 0
%tmp10 = insertelement <4 x float> %tmp, float 0.00e+00, i32 1
%tmp11 = insertelement <4 x float> %tmp10, float 0.00e+00, i32 2
%tmp12 = insertelement <4 x float> %tmp11, float 0.00e+00, i32 3
%1 = extractelement <4 x float> %tmp12, i32 0
%2 = fsub float %1, 1.00e+00
%3 = insertelement <4 x float> %tmp12, float %2, i32 0
%4 = extractelement <4 x float> %3, i32 0
%5 = fmul float %4, 5.00e-01
%6 = insertelement <4 x float> %3, float %5, i32 0
%tmp48 = tail call <4 x float> @llvm.x86.sse.min.ss(<4 x float> %6, <4 x
float> )
%tmp59 = tail call <4 x float> @llvm.x86.sse.max.ss(<4 x float> %tmp48, <4 x
float> zeroinitializer)
%tmp.upgrd.1 = tail call i32 @llvm.x86.sse.cvttss2si(<4 x float> %tmp59)
%tmp69 = trunc i32 %tmp.upgrd.1 to i16
ret i16 %tmp69
}
Output for the AVX target:
vxorps%xmm1, %xmm1, %xmm1
vaddssLCPI0_0(%rip), %xmm0, %xmm0
vmulssLCPI0_1(%rip), %xmm0, %xmm0
vblendps$1, %xmm0, %xmm1, %xmm0 ## xmm0 = xmm0[0],xmm1[1,2,3]
vminssLCPI0_2(%rip), %xmm0, %xmm0
vmaxss%xmm1, %xmm0, %xmm0
vcvttss2si%xmm0, %eax
## kill: %AX %AX %EAX
retq
This occurs because the floats constant fold forward to the final insertelement
at %6 creating a vzmovl SDNode that is lowered as a blendps or movss depending
on which features are enabled. Ideally we'd realize that the min, max, and
vcvtss2si don't need the bits are move them. I suspect running this code
through InstCombine first might figure that out.
--
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
