[llvm-bugs] [Bug 27851] New: Non-type parameter link failure in a template function with a dependent template parameter
https://llvm.org/bugs/show_bug.cgi?id=27851
Bug ID: 27851
Summary: Non-type parameter link failure in a template function
with a dependent template parameter
Product: clang
Version: 3.8
Hardware: PC
URL: http://coliru.stacked-crooked.com/a/76dbf47d66e9ba0e
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kirsha...@yahoo.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code:
---
#include
using namespace std;
template struct foo{
static constexpr T val = v;
};
template void isSame4(foo f1, foo f2) {
cout << "val1: " << f1.val << ", val2: " << f2.val << " are NOT the same"
<< endl;
}
template void isSame4(foo f1, foo f2) {
cout << "val1: " << f1.val << ", val2: " << f2.val << " are the same" <<
endl;
}
int global1 = 3;
int main() {
isSame4(foo(), foo()); // ok
isSame4(foo(), foo()); // error
}
---
Linker error:
undefined reference to `foo::val'
(Same, compiles well on g++ 6.1.0).
Related (?):
#15858: https://llvm.org/bugs/show_bug.cgi?id=15858
--
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 27851] CLOSED -- not an issue as explained in the comment
https://llvm.org/bugs/show_bug.cgi?id=27851 ak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID Summary|Non-type parameter link |CLOSED -- not an issue as |failure in a template |explained in the comment |function with a dependent | |template parameter | --- Comment #1 from ak --- The problem is with the static constexpr, and specifically when it is a pointer. This requires a separate declaration which seem to be coherent with the standard rules. -- 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 27739] Assertion `(CopyConstructor->isDefaulted() && CopyConstructor->isCopyConstructor() && !CopyConstructor->doesThisDeclarationHaveABody() && !CopyConstructor->isDeleted()) && "Def
https://llvm.org/bugs/show_bug.cgi?id=27739 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Vassil Vassilev --- Fixed in r270553. -- 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 27852] New: Unsupported FileCheck directive in CodeGen test
https://llvm.org/bugs/show_bug.cgi?id=27852 Bug ID: 27852 Summary: Unsupported FileCheck directive in CodeGen test Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: elena.lepilk...@synopsys.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified There is unsupported FileCheck directive CHECK-LABEL-DAG in test CodeGen/AArch64/combine-comparisons-by-cse.ll. FileCheck doesn't check anything in string CHECK-LABEL-DAG: .LBB9_3, because this directive is unknown. -- 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 27711] Clang does not support default calling convention options /Gd /Gr /Gv /Gz
https://llvm.org/bugs/show_bug.cgi?id=27711 Alexander Makarov 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 27853] New: incompatibility w/gcc re: ODR, template instantiation, optimization across translation units
https://llvm.org/bugs/show_bug.cgi?id=27853 Bug ID: 27853 Summary: incompatibility w/gcc re: ODR, template instantiation, optimization across translation units Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: wallstp...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16403 --> https://llvm.org/bugs/attachment.cgi?id=16403&action=edit demonstration of described behavior We've noticed a major incompatability between clang & gcc in the way that template classes are instantiated when optimization is in effect across multiple translation units. There's not much to be found in a Google search, but this post (https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/) seems to suggest that this incompatibility is intentional. This recently bit us with code similar to attached, which was attempting to define a single using a local static object. The code works as expected with g++ (4.3.3, 4.8.2, 5.3.0) at all optimization levels. Also works as expected with clang at -O0, but at -O3 the instance() method (and associated local static) appear to be inlined, which appears to violate ODR(?). The results are consistent with clang 3.7.0, trunk(r264914) and trunk(r269323). The results of running the attached code with different compilers and optimization levels: $ CXX=g++ ./test.sh -O0 test1.so:0717 W Singleton::instance() test2.so:0717 W Singleton::instance() test1.so:00200a80 u Singleton::instance()::obj test2.so:00200a80 u Singleton::instance()::obj $ CXX=g++ ./test.sh -O1 test1.so:00200910 u Singleton::instance()::obj test2.so:00200910 u Singleton::instance()::obj $ CXX=g++ ./test.sh -O2 test1.so:00200910 u Singleton::instance()::obj test2.so:00200910 u Singleton::instance()::obj $ CXX=g++ ./test.sh -O3 test1.so:00200910 u Singleton::instance()::obj test2.so:00200910 u Singleton::instance()::obj $ CXX=clang++ ./test.sh -O0 test1.so:0770 W Singleton::instance() test2.so:0770 W Singleton::instance() test1.so:00200af0 V Singleton::instance()::obj test2.so:00200af0 V Singleton::instance()::obj $ CXX=clang++ ./test.sh -O1 test1.so:0740 W Singleton::instance() test2.so:0740 W Singleton::instance() test1.so:00200a90 V Singleton::instance()::obj test2.so:00200a90 V Singleton::instance()::obj $ CXX=clang++ ./test.sh -O2 $ CXX=clang++ ./test.sh -O3 $ So, I have the following questions: - Is this behavior intended? - Is this behavior correct? Any references to rationale for this discrepancy would be much appreciated. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27854] New: [x86, SSE] insertps chosen when unpcklps would be better
https://llvm.org/bugs/show_bug.cgi?id=27854
Bug ID: 27854
Summary: [x86, SSE] insertps chosen when unpcklps would be
better
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Forking this off of bug 27826:
If we have a sequence of insertelements to fill in a vector:
define <4 x float> @goo(float %f0, float %f1, float %f2, float %f3) {
%ins0 = insertelement <4 x float> undef, float %f0, i32 0
%ins1 = insertelement <4 x float> %ins0, float %f1, i32 1
%ins2 = insertelement <4 x float> %ins1, float %f2, i32 2
%ins3 = insertelement <4 x float> %ins2, float %f3, i32 3
ret <4 x float> %ins3
}
We do the optimal thing with SSE2:
$ ./llc -o - inselts.ll
...
unpcklps%xmm3, %xmm1## xmm1 = xmm1[0],xmm3[0],xmm1[1],xmm3[1]
unpcklps%xmm2, %xmm0## xmm0 = xmm0[0],xmm2[0],xmm0[1],xmm2[1]
unpcklps%xmm1, %xmm0## xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
retq
The first two instructions are independent, so they can execute in parallel
given enough hardware.
But given the opportunity to use ever more shuffle instructions with each ISA
extension:
$ ./llc -o - inselts.ll -mattr=sse4.1
...
insertps$16, %xmm1, %xmm0 ## xmm0 = xmm0[0],xmm1[0],xmm0[2,3]
insertps$32, %xmm2, %xmm0 ## xmm0 = xmm0[0,1],xmm2[0],xmm0[3]
insertps$48, %xmm3, %xmm0 ## xmm0 = xmm0[0,1,2],xmm3[0]
retq
We now have a sequence of 3 dependent instructions, and each of those
instructions is larger in size too.
--
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 27847] Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"
https://llvm.org/bugs/show_bug.cgi?id=27847 Hans Wennborg changed: What|Removed |Added Status|RESOLVED|REOPENED 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 27843] pragma pack struct + volatile results in an unresolved external "atomic_load" when using the Microsoft Linker
https://llvm.org/bugs/show_bug.cgi?id=27843 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Component|-New Bugs |LLVM Codegen Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | --- Comment #2 from David Majnemer --- Fixed in r270576. -- 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 27855] New: bootstrap failure when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is used
https://llvm.org/bugs/show_bug.cgi?id=27855 Bug ID: 27855 Summary: bootstrap failure when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is used Product: new-bugs Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: howarth.mailing.li...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Current llvm trunk fails to bootstrap on x86_64-apple-darwin15 with the error... [ 97%] Linking CXX executable ../../bin/llvm-objdump Undefined symbols for architecture x86_64: "_xar_serialize", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_file_first", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_iter_new", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_prop_first", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_extract_tobuffersz", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_open", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_prop_get", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_close", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_prop_next", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_iter_free", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o "_xar_file_next", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string, std::__1::allocator >) in MachODump.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/build.make:173: recipe for target 'bin/llvm-objdump' failed make[2]: *** [bin/llvm-objdump] Error 1 make[2]: Target 'tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/build' not remade because of errors. CMakeFiles/Makefile2:25056: recipe for target 'tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/all' failed make[1]: *** [tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/all] Error 2 when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to the cmake options. -- 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 27856] New: Crash in handleMove during scheduling of OpenCV kernel
https://llvm.org/bugs/show_bug.cgi?id=27856 Bug ID: 27856 Summary: Crash in handleMove during scheduling of OpenCV kernel Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: llvm-bugs@lists.llvm.org, ma...@braunis.de Classification: Unclassified Created attachment 16406 --> https://llvm.org/bugs/attachment.cgi?id=16406&action=edit Testcase with new opt passes run This crashes the original testcase when http://reviews.llvm.org/D20304 is applied. A reduced version hits a verifier error instead after scheduling. llc: /home/matt/src/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1066: void llvm::LiveIntervals::HMEditor::handleMoveDown(llvm::LiveRange&): Assertion `OldIdxVNI->def == OldIdxOut->start && "Inconsistent def"' failed. Program received signal SIGABRT, Aborted. 0x7671e295 in raise () from /usr/lib/libc.so.6 (gdb) bt #0 0x7671e295 in raise () from /usr/lib/libc.so.6 #1 0x7671f6da in abort () from /usr/lib/libc.so.6 #2 0x76717297 in __assert_fail_base () from /usr/lib/libc.so.6 #3 0x76717342 in __assert_fail () from /usr/lib/libc.so.6 #4 0x01d74af7 in llvm::LiveIntervals::HMEditor::handleMoveDown (this=0x7fffca00, LR=...) at /home/matt/src/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1066 #5 0x01d7465a in llvm::LiveIntervals::HMEditor::updateRange (this=0x7fffca00, LR=..., Reg=2147484174, LaneMask=0) at /home/matt/src/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:996 #6 0x01d74394 in llvm::LiveIntervals::HMEditor::updateAllRanges (this=0x7fffca00, MI=0x46a3ec0) at /home/matt/src/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:964 #7 0x01d71bc2 in llvm::LiveIntervals::handleMove (this=0x461bd00, MI=..., UpdateFlags=true) at /home/matt/src/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1380 #8 0x01e23f1d in llvm::ScheduleDAGMI::moveInstruction (this=0x46dd0d0, MI=0x46a3ec0, InsertPos=...) at /home/matt/src/llvm/lib/CodeGen/MachineScheduler.cpp:655 #9 0x01e279f1 in llvm::ScheduleDAGMILive::scheduleMI (this=0x46dd0d0, SU=0x46ecbc0, IsTopNode=false) at /home/matt/src/llvm/lib/CodeGen/MachineScheduler.cpp:1327 #10 0x01e26973 in llvm::ScheduleDAGMILive::schedule (this=0x46dd0d0) at /home/matt/src/llvm/lib/CodeGen/MachineScheduler.cpp:1122 #11 0x01e23690 in (anonymous namespace)::MachineSchedulerBase::scheduleRegions (this=0x461c650, Scheduler=..., FixKillFlags=false) at /home/matt/src/llvm/lib/CodeGen/MachineScheduler.cpp:492 #12 0x01e22a52 in (anonymous namespace)::MachineScheduler::runOnMachineFunction (this=0x461c650, mf=...) at /home/matt/src/llvm/lib/CodeGen/MachineScheduler.cpp:357 #13 0x01decb98 in llvm::MachineFunctionPass::runOnFunction (this=0x461c690, F=...) at /home/matt/src/llvm/lib/CodeGen/MachineFunctionPass.cpp:60 #14 0x020f2957 in llvm::FPPassManager::runOnFunction (this=0x45d1d80, F=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1526 #15 0x020f2ace in llvm::FPPassManager::runOnModule (this=0x45d1d80, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1547 #16 0x020f2e1b in (anonymous namespace)::MPPassManager::runOnModule (this=0x45ed4b0, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1603 #17 0x020f34cd in llvm::legacy::PassManagerImpl::run (this=0x45e9c40, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1706 #18 0x020f36d9 in llvm::legacy::PassManager::run (this=0x7fffd5a0, M=...) at /home/matt/src/llvm/lib/IR/LegacyPassManager.cpp:1737 #19 0x00d2bcfe in compileModule (argv=0x7fffdfe8, Context=...) at /home/matt/src/llvm/tools/llc/llc.cpp:465 #20 0x00d2a804 in main (argc=8, argv=0x7fffdfe8) at /home/matt/src/llvm/tools/llc/llc.cpp:244 -- 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 27857] New: licm miscompile with noalias and call which exits program
https://llvm.org/bugs/show_bug.cgi?id=27857
Bug ID: 27857
Summary: licm miscompile with noalias and call which exits
program
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
void f() { exit(0); }
void (*ff)() = f;
void g(int* restrict a) {
for (int i = 0; i < 1000; ++i) {
ff();
*a += 1;
}
}
void (*gg)(int* restrict) = g;
int main() {
gg(0);
}
Works with gcc and clang -O0; crashes with clang -O2.
I think LICM is relying too much on "MayThrow" to conclude that function calls
will return normally.
Testcase is artificial.
--
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 27858] New: mldst-motion miscompile with call to exit()
https://llvm.org/bugs/show_bug.cgi?id=27858
Bug ID: 27858
Summary: mldst-motion miscompile with call to exit()
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
void f() { exit(1); }
void (*ff)() = f;
int r, s;
void g(int a, int*restrict p) {
if (a) {ff(); r = p[1]; }
else { s = p[1]; }
}
void (*gg)(int, int*restrict) = g;
int main() {
gg(1, 0);
}
Works with gcc or clang -O0, crashes with clang -O2.
Testcase:
#include
#include
void f() { throw 1; }
void (*ff)() = f;
void f2() {}
void (*ff2)() = f2;
int r, s;
void g(int a, int*__restrict p) {
if (a) { ff2(); p[1] = 2; ff(); }
else { p[1] = 2; }
}
void (*gg)(int, int*restrict) = g;
int main() {
int a[2] = {0};
try {
gg(1, a);
} catch (...) {}
if (a[1] != 2) abort();
}
Works with gcc or clang -O0, aborts with clang -O2.
I think the problem is
MergedLoadStoreMotion::isLoadHoistBarrierInRange/isStoreSinkBarrierInRange; you
can't use alias analysis to prove that a pointer is valid.
(Artificial testcases.)
--
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 27859] New: loop-idiom miscompile with restrict and unwinding
https://llvm.org/bugs/show_bug.cgi?id=27859
Bug ID: 27859
Summary: loop-idiom miscompile with restrict and unwinding
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
void f() { throw 1; }
void (*ff)() = f;
void g(char* __restrict base, unsigned size) {
for (unsigned i = 0; i < size; ++i) {
ff();
base[i] = 0;
}
}
void (*gg)(char*__restrict,unsigned) = g;
int main() {
char a[8] = {1};
try {
gg(a, 8);
} catch (...) {
if (a[0] != 1) abort();
}
}
Works with gcc and clang -O0, aborts with clang -O2.
There's a missing safety check in LoopIdiomRecognize.
(Artificial testcase.)
--
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 27860] New: gvn miscompile with restrict and call to exit()
https://llvm.org/bugs/show_bug.cgi?id=27860
Bug ID: 27860
Summary: gvn miscompile with restrict and call to exit()
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: eli.fried...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
void f() { exit(0); }
void (*ff)() = f;
int r;
int g(int *__restrict x, int a) {
if (a) {
r = *x;
}
ff();
return *x;
}
int (*gg)(int *__restrict, int) = g;
int main() {
gg(0, 0);
}
Works with gcc and clang -O0, segfaults with clang -O2.
Load PRE is missing a check that the pointer is actually dereferenceable.
(Artificial testcase.)
--
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 27861] New: TestObjCMethods2.py - test_NSString_expr_commands_gmodules() fails
https://llvm.org/bugs/show_bug.cgi?id=27861 Bug ID: 27861 Summary: TestObjCMethods2.py - test_NSString_expr_commands_gmodules() fails Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Once http://reviews.llvm.org/D19998 lands, this test is failing when using gmodules debugging info, on OS X 10.11.5 with the top of tree clang. -- 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 27836] Segfault of __thread varaible in Linux/ARM due to bug of LLVM ARM code generation
https://llvm.org/bugs/show_bug.cgi?id=27836 Tim Northover changed: What|Removed |Added Status|NEW |RESOLVED CC||t.p.northo...@gmail.com Resolution|--- |FIXED --- Comment #2 from Tim Northover --- As noted, this was fixed by r268662. -- 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 27855] bootstrap failure when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is used
https://llvm.org/bugs/show_bug.cgi?id=27855 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Chris Bieneman --- I think this should be fixed with r270605. -- 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 27862] New: TestRuntimeTypes.py test_break_gmodules() fails on OS X
https://llvm.org/bugs/show_bug.cgi?id=27862 Bug ID: 27862 Summary: TestRuntimeTypes.py test_break_gmodules() fails on OS X Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When http://reviews.llvm.org/D19998 lands, test_break_gmodules() will fail on OS X 10.11.5 using the top of tree clang compiler. -- 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 27863] New: TestGlobalVariables.py test_c_global_variables_gmodules() fails on OS X
https://llvm.org/bugs/show_bug.cgi?id=27863 Bug ID: 27863 Summary: TestGlobalVariables.py test_c_global_variables_gmodules() fails on OS X Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Once http://reviews.llvm.org/D19998 lands, test_c_global_variables_gmodules() is not passing when using gmodules debug info. -- 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 27863] TestGlobalVariables.py test_c_global_variables_gmodules() fails on OS X
https://llvm.org/bugs/show_bug.cgi?id=27863 Todd Fiala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Todd Fiala --- *** This bug has been marked as a duplicate of bug 25872 *** -- 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 27864] New: TestTopLevelExprs.py test_top_level_expressions_gmodules() fails on OS X
https://llvm.org/bugs/show_bug.cgi?id=27864 Bug ID: 27864 Summary: TestTopLevelExprs.py test_top_level_expressions_gmodules() fails on OS X Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Once http://reviews.llvm.org/D19998 lands, test_top_level_expressions_gmodules() fails.This is only happening with gmodules debug info. -- 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 27855] bootstrap failure when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is used
https://llvm.org/bugs/show_bug.cgi?id=27855 Jack Howarth changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Jack Howarth --- r270605 still results in a tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/link.txt without an explicit -lxar linkage... /sw/src/fink.build/llvm39-3.9.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump ../../lib/libLLVM.dylib -Wl,-rpath,@executable_path/../lib The only change I see in the linkage is for llvm-tblgen which now shows... $ otool -L llvm-tblgen llvm-tblgen: /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libxar.1.dylib (compatibility version 1.0.0, current version 1.3.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) as opposed to the previous... $ otool -L llvm-tblgen llvm-tblgen: /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /sw/opt/llvm-3.9/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0) I assume this is because of the use of add_tablegen() cmake macro in that case whereas the llvm-objdump CMakeLists.txt uses the add_llvm_tool() cmake macro. -- 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 27865] New: DeadStripTest.py test_gmodules() fails on Linux x86_64
https://llvm.org/bugs/show_bug.cgi?id=27865 Bug ID: 27865 Summary: DeadStripTest.py test_gmodules() fails on Linux x86_64 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When http://reviews.llvm.org/D19998 lands: on Ubuntu 14.04 x86_64, using top of tree clang, DeadStripTestCase.test_gmodules() fails. -- 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 27856] Crash in handleMove during scheduling of OpenCV kernel
https://llvm.org/bugs/show_bug.cgi?id=27856 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |ma...@braunis.de --- Comment #3 from Matthias Braun --- Thanks for the report and the reduced testcase. I just pushed a fix in r270619 which passes all three testcases. -- 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 27866] New: Alias to Linkonce global / canonical representation for Aliases
https://llvm.org/bugs/show_bug.cgi?id=27866 Bug ID: 27866 Summary: Alias to Linkonce global / canonical representation for Aliases Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I spent some time with Duncan today trying to understand aliases and we came to the conclusion that: @a = global i32 0 @b = alias @a should be equivalent to: @0 = private i32 0 @a = alias @0 @b = alias @0 We may even consider this as a canonical representation of aliases and have global-opt actually take care of doing this transformation. However some behavior is unexpected, right now running llvm-link with the following IR: @A = linkonce_odr global i8 1 @B = alias i8, i8* @A will generate the same IR. It means that linking @B actually introduce the symbol @A as if the alias is an actual use of the other name. Running globalopt/global-dce does not change the IR. However if we "canonicalize" to: @0 = private global i8 1 @A = linkonce_odr alias i8, i8* @0 @B = alias i8, i8* @0 Then llvm-link generates: @0 = private global i8 1 @B = alias i8, i8* @0 In this case the symbol @A will *not* be pulled in. Also, if instead of running llvm-link we run globaldce, we end up with the same result (@A is dropped). Finally globalopt is able to turn this IR into: @B = constant i8 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27867] New: PGO data for "static" functions invalidated if different build directories are used.
https://llvm.org/bugs/show_bug.cgi?id=27867 Bug ID: 27867 Summary: PGO data for "static" functions invalidated if different build directories are used. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Miscellaneous Instrumentation passes Assignee: unassignedb...@nondot.org Reporter: chisophu...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As I mentioned in the "The state of IRPGO (3 remaining work items)" thread on llvm-dev, currently we mangle the filename into the counters of static functions, which is not robust against changes in build directory. One solution would be to mangle a hash of the function into the counter name (or something like that). My main concern is IRPGO, but FEPGO probably has similar issues. For reference, here is the relevant part of that post: 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). -- 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 27868] New: Evaluating JITed expressions on arm cannot handle hard float ABI
https://llvm.org/bugs/show_bug.cgi?id=27868 Bug ID: 27868 Summary: Evaluating JITed expressions on arm cannot handle hard float ABI Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: omair.jav...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Following tests failing on arm hardware platform: TestCallUserAnonTypedef.py TestIRInterpreter.py JiTed expressions do not take into account arm hard float ABI and thus fail when we are debugging armhf targets. Also we do not handle return values of JiTed expressions when they are returned in double or single precision floating point registers. -- 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 27847] Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"
https://llvm.org/bugs/show_bug.cgi?id=27847 Michael Zolotukhin changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Michael Zolotukhin --- It also seems to be working with the latest reproducer (a.ii). -- 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 27869] New: Optimizer doesn't simplify obvious contradiction
https://llvm.org/bugs/show_bug.cgi?id=27869
Bug ID: 27869
Summary: Optimizer doesn't simplify obvious contradiction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: m...@manueljacob.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following C code contains an "obvious" contradiction. An integer can't
both be 0 and negative, so this should be simplifies to false:
_Bool test(int i) {
return (i == 0) & (i < 0);
}
The LLVM IR with SROA run on it:
define zeroext i1 @test(i32 %i) #0 {
entry:
%cmp = icmp eq i32 %i, 0
%conv = zext i1 %cmp to i32
%cmp1 = icmp slt i32 %i, 0
%conv2 = zext i1 %cmp1 to i32
%and = and i32 %conv, %conv2
%tobool = icmp ne i32 %and, 0
ret i1 %tobool
}
However running all optimizations on it will result in the following code:
define zeroext i1 @test(i32 %i) #0 {
entry:
%cmp = icmp eq i32 %i, 0
%conv = zext i1 %cmp to i32
%i.lobit = lshr i32 %i, 31
%and = and i32 %conv, %i.lobit
%tobool = icmp ne i32 %and, 0
ret i1 %tobool
}
The problem is that InstCombine transforms the (zext (< i 0)) pattern into
clever bit shifting: (lshr i 31). At first this saves one operation, but then
the obvious contradiction is obfuscated.
I see two options how to solve this:
1) Deferring the (zext (< i 0)) -> (lshr i 31) transformation, allowing
InstCombine to simplify the contradiction.
2) Making subsequent transformations more clever, so they can "look through"
the lshr instruction, seeing that it's actually a "less than" predicate.
--
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 26174] Don't override abort() and __assert_rtn() in ENABLE_CRASH_OVERRIDES when running on Lion+
https://llvm.org/bugs/show_bug.cgi?id=26174 Gerolf Hoflehner changed: What|Removed |Added Status|NEW |RESOLVED CC||ghofleh...@apple.com Resolution|--- |FIXED --- Comment #2 from Gerolf Hoflehner --- Committed revision 270643 -- 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 27870] New: [DeadArgElim] discard comdats
https://llvm.org/bugs/show_bug.cgi?id=27870
Bug ID: 27870
Summary: [DeadArgElim] discard comdats
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: david.majne...@gmail.com, llvm-bugs@lists.llvm.org,
rafael.espind...@gmail.com
Classification: Unclassified
DAE does this innocuous thing:
// Create the new function body and insert it into the module...
Function *NF = Function::Create(NFTy, Fn.getLinkage());
NF->copyAttributesFrom(&Fn);
Fn.getParent()->getFunctionList().insert(Fn.getIterator(), NF);
NF->takeName(&Fn);
But copyAttributesFrom doesn't copy comdats. I'm not sure why. Doing the
obvious thing results in these test failures:
$ git diff HEAD
diff --git a/lib/IR/Globals.cpp b/lib/IR/Globals.cpp
index 7e8ef65..3bf3cc2 100644
--- a/lib/IR/Globals.cpp
+++ b/lib/IR/Globals.cpp
@@ -96,6 +96,7 @@ void GlobalObject::copyAttributesFrom(const GlobalValue *Src)
{
if (const auto *GV = dyn_cast(Src)) {
setAlignment(GV->getAlignment());
setSection(GV->getSection());
+setComdat(const_cast(GV)->getComdat());
}
}
...
FAIL: LLVM :: Linker/comdat16.ll (10982 of 16849)
TEST 'LLVM :: Linker/comdat16.ll' FAILED
Script:
--
D:/src/llvm/build/./bin\llvm-link.EXE -S -o -
D:\src\llvm\test\Linker\comdat16.ll D:\src\llvm\test\Linker/Inputs/comdat16.ll
| D:/src/llvm/build/./bin\FileCheck.EXE D:\src\llvm\test\Linker\comdat16.ll
--
Exit Code: 2
Command Output (stdout):
--
Command 0: "D:/src/llvm/build/./bin\llvm-link.EXE" "-S" "-o" "-"
"D:\src\llvm\test\Linker\comdat16.ll"
"D:\src\llvm\test\Linker/Inputs/comdat16.ll"
Command 0 Result: 1
Command 0 Output:
Command 0 Stderr:
Declaration may not be in a Comdat!
i32* @will_be_undefined
D:/src/llvm/build/./bin\llvm-link.EXE: error: linked module is broken!
Command 1: "D:/src/llvm/build/./bin\FileCheck.EXE"
"D:\src\llvm\test\Linker\comdat16.ll"
Command 1 Result: 2
Command 1 Output:
Command 1 Stderr:
FileCheck error: '-' is empty.
--
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 194.10s
Failing Tests (3):
LLVM :: Linker/comdat11.ll
LLVM :: Linker/comdat14.ll
LLVM :: Linker/comdat16.ll
Filing so experts can look at it.
--
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 27871] New: Problematic loop-carried variable widening by InstCombine
https://llvm.org/bugs/show_bug.cgi?id=27871
Bug ID: 27871
Summary: Problematic loop-carried variable widening by
InstCombine
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: m...@manueljacob.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given the following C code:
int test(size_t n, char *a) {
char sum = 0;
for (size_t i = 0; i < n; ++i)
sum += a[i];
return sum;
}
After running a few simplifications (SROA, SimplifyCFG, LoopRotate) the IR
looks like this:
define i32 @test(i64 %n, i8* %a) #0 {
entry:
%cmp4 = icmp ult i64 0, %n
br i1 %cmp4, label %for.body, label %for.end
for.body: ; preds = %entry, %for.body
%i.06 = phi i64 [ %inc, %for.body ], [ 0, %entry ]
%sum.05 = phi i8 [ %conv2, %for.body ], [ 0, %entry ]
%arrayidx = getelementptr inbounds i8, i8* %a, i64 %i.06
%0 = load i8, i8* %arrayidx, align 1
%conv = sext i8 %0 to i32
%conv1 = sext i8 %sum.05 to i32
%add = add nsw i32 %conv1, %conv
%conv2 = trunc i32 %add to i8
%inc = add i64 %i.06, 1
%cmp = icmp ult i64 %inc, %n
br i1 %cmp, label %for.body, label %for.end
for.end: ; preds = %for.body, %entry
%sum.0.lcssa = phi i8 [ 0, %entry ], [ %conv2, %for.body ]
%conv3 = sext i8 %sum.0.lcssa to i32
ret i32 %conv3
}
I expected that running InstCombine produces code similar to this (transforming
the sext, sext, add, trunc chain to a single add instruction):
define i32 @test(i64 %n, i8* %a) #0 {
entry:
%cmp4 = icmp ult i64 0, %n
br i1 %cmp4, label %for.body, label %for.end
for.body: ; preds = %entry, %for.body
%i.06 = phi i64 [ %inc, %for.body ], [ 0, %entry ]
%sum.05 = phi i8 [ %add, %for.body ], [ 0, %entry ]
%arrayidx = getelementptr inbounds i8, i8* %a, i64 %i.06
%0 = load i8, i8* %arrayidx, align 1
%add = add nsw i8 %sum.05, %0
%inc = add i64 %i.06, 1
%cmp = icmp ult i64 %inc, %n
br i1 %cmp, label %for.body, label %for.end
for.end: ; preds = %for.body, %entry
%sum.0.lcssa = phi i8 [ 0, %entry ], [ %add, %for.body ]
%conv3 = sext i8 %sum.0.lcssa to i32
ret i32 %conv3
}
However instead InstCombine widened %sum.05 to i32 type, adding several shifts
to fix up the width:
define i32 @test(i64 %n, i8* %a) #0 {
entry:
%cmp4 = icmp eq i64 %n, 0
br i1 %cmp4, label %for.end, label %for.body
for.body: ; preds = %entry, %for.body
%i.06 = phi i64 [ %inc, %for.body ], [ 0, %entry ]
%sum.05 = phi i32 [ %add, %for.body ], [ 0, %entry ]
%arrayidx = getelementptr inbounds i8, i8* %a, i64 %i.06
%0 = load i8, i8* %arrayidx, align 1
%conv = sext i8 %0 to i32
%sext7 = shl i32 %sum.05, 24
%conv1 = ashr exact i32 %sext7, 24
%add = add nsw i32 %conv1, %conv
%inc = add i64 %i.06, 1
%cmp = icmp ult i64 %inc, %n
br i1 %cmp, label %for.body, label %for.end
for.end: ; preds = %entry, %for.body
%sum.0.lcssa = phi i32 [ 0, %entry ], [ %add, %for.body ]
%sext = shl i32 %sum.0.lcssa, 24
%conv3 = ashr exact i32 %sext, 24
ret i32 %conv3
}
Running opt -O3 again on the IR doesn't improve the code. Instead it generates
very awful code. I've attached it for reference, but there seems to be an
unrelated problem involved.
--
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
