[llvm-bugs] [Bug 31643] Clang crashes when compiling code on Windows with SEH and openmp
https://llvm.org/bugs/show_bug.cgi?id=31643 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in r292590 -- 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 31703] New: DCE optimization lost after manual inlining
https://llvm.org/bugs/show_bug.cgi?id=31703
Bug ID: 31703
Summary: DCE optimization lost after manual inlining
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: skvad...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17870
--> https://llvm.org/bugs/attachment.cgi?id=17870&action=edit
a.c, b.c
Consider the following two snippets, a.c and b.c (in attach):
// a.c:
static void f(const char *s)
{
for (; *s++ == '0'; );
}
int main(int argc, char **argv)
{
const char *s0 = argv[1];
for (int x = 0; x < 10; ++x) f(s0);
return 0;
}
// b.c is the same as a.c with 'f' inlined:
int main(int argc, char **argv)
{
const char *s0 = argv[1];
for (int x = 0; x < 10; ++x) {
for (const char *s = s0; *s++ == '0'; );
}
return 0;
}
Clang manages to optimize a.c to just 'return 0':
$ clang++-3.9 -c -O2 a.c -oa.o && objdump -d a.o
clang-3.9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated
a.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 31 c0 xor%eax,%eax
2: c3 retq
However, after manual inlining of 'f' this optimization fails:
$ clang++-3.9 -c -O2 b.c -ob.o && objdump -d b.o
clang-3.9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated
b.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 48 8b 46 08 mov0x8(%rsi),%rax
4: 31 c9 xor%ecx,%ecx
6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
d: 00 00 00
10: 48 89 c2mov%rax,%rdx
13: 66 66 66 66 2e 0f 1fdata16 data16 data16 nopw %cs:0x0(%rax,%rax,1)
1a: 84 00 00 00 00 00
20: 80 3a 30cmpb $0x30,(%rdx)
23: 48 8d 52 01 lea0x1(%rdx),%rdx
27: 74 f7 je 20
29: 48 89 c2mov%rax,%rdx
2c: 0f 1f 40 00 nopl 0x0(%rax)
30: 80 3a 30cmpb $0x30,(%rdx)
33: 48 8d 52 01 lea0x1(%rdx),%rdx
37: 74 f7 je 30
39: 48 89 c2mov%rax,%rdx
3c: 0f 1f 40 00 nopl 0x0(%rax)
40: 80 3a 30cmpb $0x30,(%rdx)
43: 48 8d 52 01 lea0x1(%rdx),%rdx
47: 74 f7 je 40
49: 48 89 c2mov%rax,%rdx
4c: 0f 1f 40 00 nopl 0x0(%rax)
50: 80 3a 30cmpb $0x30,(%rdx)
53: 48 8d 52 01 lea0x1(%rdx),%rdx
57: 74 f7 je 50
59: 48 89 c2mov%rax,%rdx
5c: 0f 1f 40 00 nopl 0x0(%rax)
60: 80 3a 30cmpb $0x30,(%rdx)
63: 48 8d 52 01 lea0x1(%rdx),%rdx
67: 74 f7 je 60
69: 83 c1 05add$0x5,%ecx
6c: 81 f9 00 ca 9a 3b cmp$0x3b9aca00,%ecx
72: 75 9c jne10
74: 31 c0 xor%eax,%eax
76: c3 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 23871] Passing a string literal to a .byte directive crashes the assembler
https://llvm.org/bugs/show_bug.cgi?id=23871 Sanne Wouda changed: What|Removed |Added Status|NEW |RESOLVED CC||sanne.wo...@arm.com Resolution|--- |FIXED --- Comment #2 from Sanne Wouda --- This was, accidentally, fixed in https://reviews.llvm.org/rL264156 . -- 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 31704] New: SBModule::FindFirstType does not find a second namespaced typedef with the same name
https://llvm.org/bugs/show_bug.cgi?id=31704
Bug ID: 31704
Summary: SBModule::FindFirstType does not find a second
namespaced typedef with the same name
Product: lldb
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: alexandru.croi...@qt.io
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17871
--> https://llvm.org/bugs/attachment.cgi?id=17871&action=edit
Example code which shows the issue regarding FindFirstType
SBModule::FindFirstType has an issue with finding namespaced typedefs.
Consider the code:
class Foo {
public:
typedef bool MyType;
};
class Bar {
public:
typedef int MyType;
};
int main(int argc, char* argv[]) {
Foo::MyType foo;
Bar::MyType bar;
(void) foo;
(void) bar;
return 0;
}
Compile with clang++ -O0 -g ./main.cpp
Run with lldb ./a.out and go into python script mode
>>> lldb.target.FindTypes("MyType").GetSize()
2
>>> print lldb.target.FindFirstType("MyType")
typedef Foo::MyType
>>> print lldb.target.FindFirstType("Foo::MyType")
typedef Foo::MyType
>>> print lldb.target.FindFirstType("Bar::MyType")
As you can see, trying to find Bar::MyType fails, but if I iterate over
FindTypes result, I can find both.
(lldb) version
lldb-360.99.0
clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad
llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35
The issue seems to be inside lldb::TypeSP Module::FindFirstType(const
SymbolContext &sc, const ConstString &name, bool exact_match)
which passes "1" as the max_matches argument, and this gets propagated in a
wrong way inside the implementation, where essentially a list of the two types
is found, and the second type is not checked because the first type didn't
match.
--
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 31705] New: warn when loop condition comparison uses different size operands
https://llvm.org/bugs/show_bug.cgi?id=31705
Bug ID: 31705
Summary: warn when loop condition comparison uses different
size operands
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: nivek.resea...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I recently encountered a infinite loop where the variable in a for loop
overflowed before reaching the termination value. For example, the 16-bit
unsigned int below is compared to a 64-bit unsigned long (on macOS) and since
the 16-bit value will overflow after 65535 it never reaches 65536 and the loop
will never terminates. I think it would be a great check for either the
compiler or more probably the static analyzer to warn that loop may not
terminate because of comparison may always be false due to overflow. I believe
the check would be good for for, while and do until loops.
#include
#include
#include
int main() {
size_t limit = 65536;
for (uint16_t index = 0; index < limit; index++) {
}
printf("completedi\n");
}
I believe similar warnings could be reported for
uint16_t index = 0;
while (index < limit) {
index++;
}
and
do {
index++;
} while (index < limit);
The compiler does produce a warning if limit is replaced by a constant value:
main.cpp:11:15: warning: comparison of constant 65536 with expression of type
'uint16_t' (aka 'unsigned short') is always true
[-Wtautological-constant-out-of-range-compare]
while (index < 65536) {
~ ^ ~
So perhaps this can just be enhanced.
--
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 31706] New: SBTarget::FindTypes does not find resolved function pointer types
https://llvm.org/bugs/show_bug.cgi?id=31706
Bug ID: 31706
Summary: SBTarget::FindTypes does not find resolved function
pointer types
Product: lldb
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: alexandru.croi...@qt.io
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17872
--> https://llvm.org/bugs/attachment.cgi?id=17872&action=edit
Example code which shows the issue regarding FindTypes
SBTarget::FindTypes does not find resolved function pointer types, which were
declared as function pointer typedefs.
Consider the code:
typedef struct _type {
int value;
} MyType;
typedef void (*FunctionPointer)(MyType*);
void function(MyType* t) {
(void) t;
}
int main(int argc, char* argv[]) {
MyType t;
FunctionPointer fp = &function;
fp(&t);
return 0;
}
Compile with clang++ -O0 -g ./main.cpp
Run lldb ./a.out and go into python script mode, then:
>>> lldb.target.FindTypes("FunctionPointer").GetSize()
1
>>> lldb.target.FindTypes("void (*)(MyType*)").GetSize()
0
>>> lldb.target.FindTypes("void (*)(MyType *)").GetSize()
0
But if I do:
>>> for t in lldb.target.GetModuleAtIndex(0).GetTypes():
... print t.GetName()
I get:
FunctionPointer
void (*)(MyType *)
MyType *
MyType
_type
void (MyType *)
main
char **
char *
char
int
which obviously contains "void (*)(MyType *)" which I have searched for
previously.
dwardump-ing the executable dSYM I can see DWARF data for the typedef, but not
for the underlying type of the typedef.
Is this a bug? Should FindTypes find resolved typedefs? Or is this intended
behavior?
(lldb) version
lldb-360.99.0
clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad
llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35
--
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 31707] New: Settings breakpoints using absolute file path that contains symlinks does not work
https://llvm.org/bugs/show_bug.cgi?id=31707 Bug ID: 31707 Summary: Settings breakpoints using absolute file path that contains symlinks does not work Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: alexandru.croi...@qt.io CC: llvm-bugs@lists.llvm.org Classification: Unclassified Consider I have a C++ file at: /Users/alex/Dev/project/main.cpp and I compiled the file there with: clang++ -g -O0 ./main.cpp Now if I try to set a breakpoint with: br set -f /Users/alex/Dev/project/main.cpp -l 10 the breakpoint will work. But if I try to set a breakpoint with: br set -f /Volumes/Macintosh\ HD/Users/alex/Dev/project/main.cpp -l 10 the breakpoint will not work, because it differs from the DWARF written filepath. Machintosh HD is a symlink to / $ ls -al /Volumes/ lrwxr-xr-x 1 root admin 1 Dec 23 07:40 Macintosh HD -> / Should lldb maybe consider using the canonical path to a given file, when setting a breakpoint? (lldb) version lldb-360.99.0 clang revision a41b64721d4be78870711cbb7b5af156a9e1f4ad llvm revision 3c45ea423a9e3d27eaf77af0639a73e0c56d9a35 -- 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 31708] New: signext of small integer return types ignored
https://llvm.org/bugs/show_bug.cgi?id=31708 Bug ID: 31708 Summary: signext of small integer return types ignored 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: eric.schwe...@pgroup.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17873 --> https://llvm.org/bugs/attachment.cgi?id=17873&action=edit Small test file to show x86 signext i16 returns In the attached .ll file is a small function that has a return type of "signext i16". From the LLVM Language Reference, it seems that the value returned ought to be sign extended to the word width (i32) of the target in this case. Experimentation showed that sign extension was the case in 3.8. movswl -2(%rsp), %eax However, in 3.9 the sign extension changed to a zero extension. movzwl -2(%rsp), %eax This zero extension can be seen in my latest "master" branch build as well. To reproduce: llc -O1 -o bug.s bug.ll -- 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 31709] New: compiler warning padding lambda
https://llvm.org/bugs/show_bug.cgi?id=31709
Bug ID: 31709
Summary: compiler warning padding lambda
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: nivek.resea...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The clang compiler may warn that lambda's are padded
# clang++ -std=c++11 -stdlib=libc++ -Weverything -Wno-c++98-compat main.cpp
main.cpp:22:13: warning: padding class '(lambda at main.cpp:20:45)' with 4
bytes to align anonymous bit-field [-Wpadded]
document->prepare();
^
1 warning generated.
I believe one no control over how the compiler stores the state for the lambda
so I believe the warning should not be shown.
#include
#include
class Document {
public:
bool unlock(void) { return true; }
void prepare(void) {}
void perform(void) {}
};
uint32_t GetCurrentEventKeyModifiers(void);
void UnlockDocumentAndCallFunction(Document* const inDocument,
std::function const inFunction);
int main() {
Document* const document = new Document();
uint32_t const modifiers = GetCurrentEventKeyModifiers();
UnlockDocumentAndCallFunction(document, [=]() {
if (modifiers & 1) {
document->prepare();
}
document->perform();
});
delete document;
return 0;
}
uint32_t GetCurrentEventKeyModifiers(void) {
return 1;
}
void UnlockDocumentAndCallFunction(Document* const inDocument,
std::function const inFunction) {
if (inDocument->unlock()) {
inFunction();
}
}
--
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 31710] New: Assertion `ChainNode->getOpcode() != ISD::DELETED_NODE && "Deleted node left in chain"' failed.
https://llvm.org/bugs/show_bug.cgi?id=31710 Bug ID: 31710 Summary: Assertion `ChainNode->getOpcode() != ISD::DELETED_NODE && "Deleted node left in chain"' failed. Product: clang Version: 4.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: k...@neutralgood.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17874 --> https://llvm.org/bugs/attachment.cgi?id=17874&action=edit The reduced bitcode that triggers the assertion. Bug found when running 4.0.0rc1 on Linux on System/Z. + exec /sas3rd/wky/mva-alzx/lzx/llvm/llvm-400rc1/install/stock/bin/llc bugpoint-reduced-simplified.bc llc: /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2264: void llvm::SelectionDAGISel::UpdateChains(llvm::SDNode*, llvm::SDValue, const llvm::SmallVectorImpl&, bool): Assertion `ChainNode->getOpcode() != ISD::DELETED_NODE && "Deleted node left in chain"' failed. #0 0x81a66d8a llvm::sys::PrintStackTrace(llvm::raw_ostream&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Support/Unix/Signals.inc:402:0 #1 0x81a6719a PrintStackTraceSignalHandler(void*) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Support/Unix/Signals.inc:466:0 #2 0x81a64dc6 llvm::sys::RunSignalHandlers() /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Support/Signals.cpp:44:0 #3 0x81a66406 SignalHandler(int) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Support/Unix/Signals.inc:253:0 #4 0x946e039e #5 0x03ffa49ba830 __GI_raise /usr/src/debug/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x03ffa49bc0b8 __GI_abort /usr/src/debug/glibc-2.17-c758a686/stdlib/abort.c:92:0 #7 0x03ffa49b2886 __assert_fail_base /usr/src/debug/glibc-2.17-c758a686/assert/assert.c:53:0 #8 0x03ffa49b2914 (/lib64/libc.so.6+0x32914) #9 0x8187ebf6 llvm::SelectionDAGISel::UpdateChains(llvm::SDNode*, llvm::SDValue, llvm::SmallVectorImpl const&, bool) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2268:0 #10 0x81887582 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3540:0 #11 0x8088b294 (anonymous namespace)::SystemZDAGToDAGISel::SelectCode(llvm::SDNode*) /sasusr/u/saskpn/clvm/4.0.0rc1/LZXND/lib/Target/SystemZ/SystemZGenDAGISel.inc:25634:0 #12 0x80895280 (anonymous namespace)::SystemZDAGToDAGISel::Select(llvm::SDNode*) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Target/SystemZ/SystemZISelDAGToDAG.cpp:1350:0 #13 0x81877f5c llvm::SelectionDAGISel::DoInstructionSelection() /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:955:0 #14 0x81877640 llvm::SelectionDAGISel::CodeGenAndEmitDAG() /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:861:0 #15 0x81875cfc llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>, llvm::ilist_iterator, false, true>, bool&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:684:0 #16 0x8187afc8 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1561:0 #17 0x8187497e llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:509:0 #18 0x8088b1c2 (anonymous namespace)::SystemZDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/Target/SystemZ/SystemZISelDAGToDAG.cpp:338:0 #19 0x80ed09e2 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0 #20 0x8147e726 llvm::FPPassManager::runOnFunction(llvm::Function&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/IR/LegacyPassManager.cpp:1513:0 #21 0x8147e974 llvm::FPPassManager::runOnModule(llvm::Module&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/IR/LegacyPassManager.cpp:1534:0 #22 0x8147ee3c (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/IR/LegacyPassManager.cpp:1590:0 #23 0x8147f730 llvm::legacy::PassManagerImpl::run(llvm::Module&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/IR/LegacyPassManager.cpp:1693:0 #24 0x8147fa90 llvm::legacy::PassManager::run(llvm::Module&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/lib/IR/LegacyPassManager.cpp:1724:0 #25 0x807fef7a compileModule(char**, llvm::LLVMContext&) /sasusr/u/saskpn/clvm/4.0.0rc1/llvm/tools/llc/llc.cpp:530:0 #26 0x807fd330 main /sasusr/u/saskpn/clvm/
[llvm-bugs] [Bug 31711] New: Cherry pick r292625 to 4.0 branch
https://llvm.org/bugs/show_bug.cgi?id=31711 Bug ID: 31711 Summary: Cherry pick r292625 to 4.0 branch Product: libraries Version: 4.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'd like to propose r292625 to be cherry picked to the llvm 4.0 branch. It's a straightforward low risk patch that fixes kill flags in the backend. It likely won't affect any users directly, however this would help when running bots with -verify-machineinstrs to ensure release quality. -- 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 31712] New: Do we need X86ISD::VSEXT and X86ISD::VZEXT?
https://llvm.org/bugs/show_bug.cgi?id=31712 Bug ID: 31712 Summary: Do we need X86ISD::VSEXT and X86ISD::VZEXT? 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: craig.top...@gmail.com, elena.demikhov...@intel.com, llvm-bugs@lists.llvm.org, mku...@google.com, spatel+l...@rotateright.com Blocks: 30624 Classification: Unclassified Everything that X86ISD::VSEXT/X86ISD::VZEXT does can be performed with the ISD SIGN/ZERO_EXTEND and SIGN/ZERO_EXTEND_VECTOR_IN_REG ops. Using these directly would help us reuse existing generic combines and would probably assist with (or at least avoid) various legalization/canonicalization issues (such as what is going on with D28537). AVX512 predicate mask extension may be tricky but it might make sense to keep the X86ISD opcodes just for those cases, at least initially. -- 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 30411] multiple piglit builtin-char* and others test regressed
https://llvm.org/bugs/show_bug.cgi?id=30411 Jan Vesely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Vesely --- Fixed in r292651. -- 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 28915] multiple piglit builtin-short* and builtin-ushort tests fails
https://llvm.org/bugs/show_bug.cgi?id=28915 Jan Vesely changed: What|Removed |Added Status|NEW |RESOLVED CC||jan.ves...@rutgers.edu Resolution|--- |FIXED --- Comment #1 from Jan Vesely --- Fixed in r292651. -- 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 31686, which changed state. Bug 31686 Summary: NewGVN miscompile (leader for store change) https://llvm.org/bugs/show_bug.cgi?id=31686 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 31686] NewGVN miscompile (leader for store change)
https://llvm.org/bugs/show_bug.cgi?id=31686 Davide Italiano changed: 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 31698] NewGVN fails to do store to load forwarding
https://llvm.org/bugs/show_bug.cgi?id=31698 Davide Italiano changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||dav...@freebsd.org 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 30995] [META][GVN] NewGVN Integration
https://llvm.org/bugs/show_bug.cgi?id=30995 Bug 30995 depends on bug 31698, which changed state. Bug 31698 Summary: NewGVN fails to do store to load forwarding https://llvm.org/bugs/show_bug.cgi?id=31698 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 30995] [META][GVN] NewGVN Integration
https://llvm.org/bugs/show_bug.cgi?id=30995 Bug 30995 depends on bug 31613, which changed state. Bug 31613 Summary: NewGVN asserts, "instruction processed too many times" https://llvm.org/bugs/show_bug.cgi?id=31613 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 31613] NewGVN asserts, "instruction processed too many times"
https://llvm.org/bugs/show_bug.cgi?id=31613 Davide Italiano changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Davide Italiano --- r291968 fixed this one. -- 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] Failure to recognise some integer MIN/MAX CLAMP patterns
https://llvm.org/bugs/show_bug.cgi?id=31693 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rL292660 -- 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 31713] New: lli with --force-interpreter crushed when read/store struct type from memory
https://llvm.org/bugs/show_bug.cgi?id=31713 Bug ID: 31713 Summary: lli with --force-interpreter crushed when read/store struct type from memory Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Generic Execution Engine Support Assignee: unassignedb...@nondot.org Reporter: yanyeqing1...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Function ExecutionEngine::LoadValueFromMemory() and ExecutionEngine::StoreValueToMemory() didn't handle the case Type::StructTyID. -- 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 31714] New: Incorrect use of phsubw
https://llvm.org/bugs/show_bug.cgi?id=31714
Bug ID: 31714
Summary: Incorrect use of phsubw
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: andrew.b.ad...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following .ll defines two functions. The first computes the absolute
difference between adjacent elements in a vector (a > b ? a - b : b - a). The
second just computes the difference (a - b):
define <8 x i16> @horizontal_abs_diff(<16 x i16> * %src) {
%v1 = load <16 x i16>, <16 x i16>* %src
%evens = shufflevector <16 x i16> %v1, <16 x i16> undef, <8 x i32>
%odds = shufflevector <16 x i16> %v1, <16 x i16> undef, <8 x i32>
%d1 = sub <8 x i16> %evens, %odds
%d2 = sub <8 x i16> %odds, %evens
%cmp = icmp ugt <8 x i16> %evens, %odds
%res = select <8 x i1> %cmp, <8 x i16> %d1, <8 x i16> %d2
ret <8 x i16> %res
}
define <8 x i16> @horizontal_diff(<16 x i16> * %src) {
%v1 = load <16 x i16>, <16 x i16>* %src
%evens = shufflevector <16 x i16> %v1, <16 x i16> undef, <8 x i32>
%odds = shufflevector <16 x i16> %v1, <16 x i16> undef, <8 x i32>
%d1 = sub <8 x i16> %evens, %odds
ret <8 x i16> %d1
}
When compiled for an architecture with phsubw, both produce the same assembly:
$ llc repro.ll -mcpu=core2 -filetype=asm -o -
.text
.def horizontal_abs_diff;
.scl2;
.type 32;
.endef
.globl horizontal_abs_diff
.p2align4, 0x90
horizontal_abs_diff:# @horizontal_abs_diff
# BB#0:
movdqa (%rcx), %xmm0
phsubw 16(%rcx), %xmm0
retq
.def horizontal_diff;
.scl2;
.type 32;
.endef
.globl horizontal_diff
.p2align4, 0x90
horizontal_diff:# @horizontal_diff
# BB#0:
movdqa (%rcx), %xmm0
phsubw 16(%rcx), %xmm0
retq
That code just computes the horizontal difference in both cases, and so the
outputs are incorrect for the absolute difference case. Compiling without
phsubw available produces meaningfully two different functions, and the outputs
are correct:
$ ../llvm/trunk/build/bin/llc repro.ll -mcpu=native -mattr=-ssse3 -filetype=asm
-o -
.text
.def horizontal_abs_diff;
.scl2;
.type 32;
.endef
.section.rdata,"dr"
.p2align4
.LCPI0_0:
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.short 32768 # 0x8000
.text
.globl horizontal_abs_diff
.p2align4, 0x90
horizontal_abs_diff:# @horizontal_abs_diff
# BB#0:
movdqa (%rcx), %xmm1
movdqa 16(%rcx), %xmm2
pshuflw $232, %xmm2, %xmm0 # xmm0 = xmm2[0,2,2,3,4,5,6,7]
pshufhw $232, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2,3,4,6,6,7]
pshufd $232, %xmm0, %xmm3 # xmm3 = xmm0[0,2,2,3]
pshuflw $232, %xmm1, %xmm0 # xmm0 = xmm1[0,2,2,3,4,5,6,7]
pshufhw $232, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2,3,4,6,6,7]
pshufd $232, %xmm0, %xmm0 # xmm0 = xmm0[0,2,2,3]
punpcklqdq %xmm3, %xmm0# xmm0 = xmm0[0],xmm3[0]
pshuflw $231, %xmm2, %xmm2 # xmm2 = xmm2[3,1,2,3,4,5,6,7]
pshufhw $231, %xmm2, %xmm2 # xmm2 = xmm2[0,1,2,3,7,5,6,7]
pshufd $232, %xmm2, %xmm2 # xmm2 = xmm2[0,2,2,3]
pshuflw $177, %xmm2, %xmm2 # xmm2 = xmm2[1,0,3,2,4,5,6,7]
pshuflw $231, %xmm1, %xmm1 # xmm1 = xmm1[3,1,2,3,4,5,6,7]
pshufhw $231, %xmm1, %xmm1 # xmm1 = xmm1[0,1,2,3,7,5,6,7]
pshufd $232, %xmm1, %xmm1 # xmm1 = xmm1[0,2,2,3]
pshuflw $177, %xmm1, %xmm1 # xmm1 = xmm1[1,0,3,2,4,5,6,7]
punpcklqdq %xmm2, %xmm1# xmm1 = xmm1[0],xmm2[0]
movdqa %xmm0, %xmm2
psubw %xmm1, %xmm2
movdqa %xmm1, %xmm3
psubw %xmm0, %xmm3
movdqa .LCPI0_0(%rip), %xmm4 # xmm4 =
[32768,32768,32768,32768,32768,32768,32768,32768]
pxor%xmm4, %xmm0
pxor%xmm4, %xmm1
pcmpgtw %xmm1, %xmm0
pand%xmm0, %xmm2
pandn %xmm3, %xmm0
por %xmm2, %xmm0
retq
.def horizontal_diff;
.scl2;
.type 32;
.endef
.globl horizontal_diff
.p2align4, 0x90
horizontal_diff:# @horizontal_diff
# BB#
[llvm-bugs] [Bug 31714] Incorrect use of phsubw
https://llvm.org/bugs/show_bug.cgi?id=31714 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Craig Topper --- Should be fixed in r292713. -- 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
