[llvm-bugs] [Bug 45676] New: lldb wrongly stopped at a break statement when using step-by-step
https://bugs.llvm.org/show_bug.cgi?id=45676
Bug ID: 45676
Summary: lldb wrongly stopped at a break statement when using
step-by-step
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ lldb -v
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/home/yibiao/a.out' (x86_64).
(lldb) b small.c:14
Breakpoint 1: where = a.out`main + 57 at small.c:14:16, address =
0x00401149
(lldb) run
Process 237374 launched: '/home/yibiao/a.out' (x86_64)
Process 237374 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401149 a.out`main at small.c:14:16
11 for (; g <= 32; ++g)
12 {
13 i = 0;
-> 14 for (; i < 1; i++)
15 while (1 > d)
16 if (c[b])
17 break;
(lldb) step
Process 237374 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x00401153 a.out`main at small.c:15:9
12 {
13 i = 0;
14 for (; i < 1; i++)
-> 15 while (1 > d)
16 if (c[b])
17 break;
18 L:
(lldb) step
Process 237374 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x00401193 a.out`main at small.c:14:22
11 for (; g <= 32; ++g)
12 {
13 i = 0;
-> 14 for (; i < 1; i++)
15 while (1 > d)
16 if (c[b])
17 break;
(lldb) step
Process 237374 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401149 a.out`main at small.c:14:16
11 for (; g <= 32; ++g)
12 {
13 i = 0;
-> 14 for (; i < 1; i++)
15 while (1 > d)
16 if (c[b])
17 break;
(lldb) step
Process 237374 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x004011a1 a.out`main at small.c:17:13
14 for (; i < 1; i++)
15 while (1 > d)
16 if (c[b])
-> 17 break;
18 L:
19 if (j)
20 break;
##
We can found that, lldb is wrongly stopped at Line:17 when using step command.
However, it behaves as expected when we set breakpoint at line:17 as follows:
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/home/yibiao/a.out' (x86_64).
(lldb) b small.c:17
Breakpoint 1: where = a.out`main + 116 at small.c:17:13, address =
0x00401184
(lldb) run
Process 236754 launched: '/home/yibiao/a.out' (x86_64)
Process 236754 exited with status = 0 (0x)
$ cat small.c
char a;
short b, d = 5, h;
char c[1];
int e, f = 4, g, j;
int main()
{
int i;
for (; f; f = a)
{
g = 0;
for (; g <= 32; ++g)
{
i = 0;
for (; i < 1; i++)
while (1 > d)
if (c[b])
break;
L:
if (j)
break;
}
}
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45677] New: [arm] After 186155b89c2d, fatal error: error in backend: Cannot select: t28: i32 = ARMISD::QADD8b t33, t35
https://bugs.llvm.org/show_bug.cgi?id=45677
Bug ID: 45677
Summary: [arm] After 186155b89c2d, fatal error: error in
backend: Cannot select: t28: i32 = ARMISD::QADD8b t33,
t35
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Recently I got the following fatal backend error when building
https://github.com/freebsd/freebsd/blob/master/sys/dev/sound/pcm/feeder_mixer.c
for armv5 (on FreeBSD this apparently defaults to -target-cpu arm1022e):
fatal error: error in backend: Cannot select: t37: i32 = ARMISD::QADD8b t43,
t44
t43: i32,ch = load<(load 1 from %ir.8, !tbaa !65), sext from i8> t0, t5,
undef:i32
t5: i32 = add t2, t4
t2: i32,ch = CopyFromReg t0, Register:i32 %1
t1: i32 = Register %1
t4: i32,ch = CopyFromReg t0, Register:i32 %2
t3: i32 = Register %2
t14: i32 = undef
t44: i32,ch = load<(load 1 from %ir.11, !tbaa !65), sext from i8> t0, t8,
undef:i32
t8: i32 = add t7, t4
t7: i32,ch = CopyFromReg t0, Register:i32 %0
t6: i32 = Register %0
t4: i32,ch = CopyFromReg t0, Register:i32 %2
t3: i32 = Register %2
t14: i32 = undef
In function: feed_mixer_S8NE
The full test case reduces to:
// clang -cc1 -triple armv5e--- -S -target-cpu arm1022e -O1 feeder_mixer-min.c
char *a;
char b;
int c;
void d() {
int e, f = *(signed char *)a;
c = *(signed char *)1;
e = f + c;
f = e > 127 ? 127 : e < -0x80 ? 128 : e;
b = f;
}
Interestingly, this regressed with the *very* last Subversion commit to trunk,
https://reviews.llvm.org/rL375505 ("[InstCombine] Signed saturation patterns"),
a.k.a. https://reviews.llvm.org/rG186155b89c2d, and
https://reviews.llvm.org/D68651.
It still reproduces with recent llvm master.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45645] Using --relocatable with mismatching function signatures crashes
https://bugs.llvm.org/show_bug.cgi?id=45645 Heejin Ahn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Heejin Ahn --- Fixed by Sam in https://github.com/llvm/llvm-project/commit/4b8e2d8e81adf3aa1ea79fe0b908100c4ea69f65. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39169] Incorrect accessibility check when using decltype inside class definition
https://bugs.llvm.org/show_bug.cgi?id=39169 language.law...@gmail.com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||language.law...@gmail.com --- Comment #3 from language.law...@gmail.com --- *** This bug has been marked as a duplicate of bug 27225 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 21858 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::InnerLoopVectorizer::getOrCreateVectorValue
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 21858 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::InnerLoopVectorizer::getOrCreateVectorValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21858#c1 ClusterFuzz testcase 4917131507662848 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202004240246:202004250445 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45678] New: llvm-cov: wrong coverage for a loop statement within switch block
https://bugs.llvm.org/show_bug.cgi?id=45678
Bug ID: 45678
Summary: llvm-cov: wrong coverage for a loop statement within
switch block
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@hust.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.3.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.c.lcov; cat
small.c.lcov
1| |int main()
2| 1|{
3| 1| int size = 4, ret = 0;
4| 1|
5| 1| switch (size)
6| 1| {
7| 0|for(;;)
8| 3|{
9| 3| ret++;
10| 3|case 3:
11| 3| ret++;
12| 4|case 4:
13| 4| if (size <= 1)
14| 1|break;
15| 3| size -= 1;
16| 3|}
17| 1| }
18| 1| return 0;
19| 1|}
We found that, Line #7 is marked as not execute. However, Line 8,9,10,and 11
are both executed three times. The loop statement should executed at least
three times.
For example, when we setting breakpoint at this small.c:7, lldb will stopped at
this statement as follows:
$ clang -g small.c; lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/home/yibiao/a.out' (x86_64).
(lldb) b small.c:7
Breakpoint 1: where = a.out`main + 106 at small.c:7:5, address =
0x0040117a
(lldb) run
Process 275921 launched: '/home/yibiao/cv-gcov/a.out' (x86_64)
Process 275921 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040117a a.out`main at small.c:7:5
4
5 switch (size)
6 {
-> 7for(;;)
8{
9 ret++;
10 case 3:
$ cat small.c
int main()
{
int size = 4, ret = 0;
switch (size)
{
for(;;)
{
ret++;
case 3:
ret++;
case 4:
if (size <= 1)
break;
size -= 1;
}
}
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31322] crash in FlattenCFG: MergeIfRegion
https://bugs.llvm.org/show_bug.cgi?id=31322 Ehud Katz changed: What|Removed |Added Fixed By Commit(s)||rGd98cb81cd11c CC||ehudk...@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40925] opt crashes with "with "opt -flattencfg" : Assertion `Val && "isa<> used on a null pointer"' failed.
https://bugs.llvm.org/show_bug.cgi?id=40925 Ehud Katz changed: What|Removed |Added CC||ehudk...@gmail.com Fixed By Commit(s)||rGd98cb81cd11c Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45679] New: LoopVectorizer produces wrong code with UserVF not dividing small TripCount
https://bugs.llvm.org/show_bug.cgi?id=45679 Bug ID: 45679 Summary: LoopVectorizer produces wrong code with UserVF not dividing small TripCount Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: ayal.z...@intel.com CC: dorit.nuz...@intel.com, florian_h...@apple.com, gil.rapap...@intel.com, llvm-bugs@lists.llvm.org Created attachment 23402 --> https://bugs.llvm.org/attachment.cgi?id=23402&action=edit Reproducer Compiling the attached with opt -loop-vectorize -force-vector-width=4 -S vectorizes a loop with trip-count=14 using VF=4 w/o a tail, explaining that: LV: Found trip count: 14 LV: Not allowing scalar epilogue due to low trip count. LV: Performing code size checks. LV: The Smallest and Widest types: 32 / 32 bits. LV: The Widest register safe to use is: 32 bits. LV: No tail will remain for any chosen VF. <== but LV doesn't get to chose VF LV: Using user VF 4. Culprit is computeMaxVF() who checks if TC % MaxVF == 0 where MaxVF = computeFeasibleMaxVF(TC) (=1 in this case), even if a UserVF is given and ultimately used. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45681] New: Request for LangRef clarification: allocation size of global variable declaration
https://bugs.llvm.org/show_bug.cgi?id=45681 Bug ID: 45681 Summary: Request for LangRef clarification: allocation size of global variable declaration Product: Documentation Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: mschif...@universe-factory.net CC: llvm-bugs@lists.llvm.org Working on Rust, we have come across the question whether LLVM makes any assumptions about the allocation size of declared global variables based on their type when the definition is unknown (or, turning it around, if it is guaranteed that LLVM makes no such assumptions). It seems fine to access data (for example using getelementptr inbounds) past the "end" of such a global variable at least on some cases - I've noticed that clang compiles a `extern char foo[];` to `@foo = external global [0 x i8], align 1` (and a comment in llvm/test/Analysis/BasicAA/global-size.ll backs this). What is not entirely clear to us is whether such accesses are *always* valid (given that a definition of appropriate length comes in at link time), in particular: - when the length of the declared type is not 0 - when the declared type is not an array, but a struct, and the last element of the struct is no array If all of this is indeed valid, it would be great if such a statement could be added to the LangRef. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45648] clang-format breaks right shift operators
https://bugs.llvm.org/show_bug.cgi?id=45648 Owen Pan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Owen Pan --- *** This bug has been marked as a duplicate of bug 45218 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45682] New: Failure to optimize some limit bounds patterns based on __builtin_assume
https://bugs.llvm.org/show_bug.cgi?id=45682
Bug ID: 45682
Summary: Failure to optimize some limit bounds patterns based
on __builtin_assume
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
#include
#ifdef __clang__
#define assume __builtin_assume
#else
inline void assume(bool x)
{
if (!x)
__builtin_unreachable();
}
#endif
void g();
void f(int x, int y)
{
assume(y > 0);
x += y;
if (x == -INT_MAX - 1)
g();
}
`f` is optimized to doing nothing by gcc, clang does the check even though `y >
0` means the last condition is always false. Sample comparison here :
https://godbolt.org/z/x-cuqX
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45683] New: Bad optimization of simple switch
https://bugs.llvm.org/show_bug.cgi?id=45683
Bug ID: 45683
Summary: Bad optimization of simple switch
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(unsigned x)
{
switch (x)
{
case 0:
return 1;
case 1:
return 2;
}
}
This gets optimized to some rather weird code (uses `sbb` on x86) when it could
just be optimized to `return x + 1`. See here for an example of the bad
generation : https://godbolt.org/z/2fQmpH
Maybe we could change the translation of `select` (as it is used in the IR this
translates to) in order to detect cases such as this and optimize them properly
?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45684] New: Failure to optimize out unary - on right operand of % when it is not -1
https://bugs.llvm.org/show_bug.cgi?id=45684
Bug ID: 45684
Summary: Failure to optimize out unary - on right operand of %
when it is not -1
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int x, int y)
{
__builtin_assume(y != -1);
return x % -y;
}
Here, `x % -y` could be optimized to `x % y`, since `y != -1`. GCC does this
transformation, but LLVM does not.
Comparison here : https://godbolt.org/z/utdr2q
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45685] New: Failure to optimize away multiplication when right operand is not 0
https://bugs.llvm.org/show_bug.cgi?id=45685
Bug ID: 45685
Summary: Failure to optimize away multiplication when right
operand is not 0
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b, int c)
{
__builtin_assume(c != 0);
a *= c;
b *= c;
return a == b;
}
This could all be optimized into `a == b` since `c != 0`. This transformation
is done by GCC, but not by LLVM.
Comparison here : https://godbolt.org/z/SMWp9P
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45686] New: Failure to combine assumptions on range of value of variable
https://bugs.llvm.org/show_bug.cgi?id=45686
Bug ID: 45686
Summary: Failure to combine assumptions on range of value of
variable
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void foo(int a, int b, bool c)
{
__builtin_assume(a < 234);
__builtin_assume(b > 789);
int d = (c ? a : b);
if (d >= 234 && d <= 789)
g();
}
GCC optimizes the entire function out, LLVM does not. Most likely we'd want
LLVM to combine the assumptions on `a` and `b` in such a way that `d >= 234 &&
d <= 789` would be considered always false afterwards
Comparison here : https://godbolt.org/z/f4uWiY
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45687] New: Failure to optimize away abs check based on known range of variable
https://bugs.llvm.org/show_bug.cgi?id=45687
Bug ID: 45687
Summary: Failure to optimize away abs check based on known
range of variable
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void g();
void f(int i)
{
__builtin_assume(i >= -1 && i <= 1);
if (abs(i) > 1)
g();
}
This can all be optimized out. GCC does this transformation, LLVM does not.
Comparison here : https://godbolt.org/z/cLcicG
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45688] New: Missed optimization on comparison after knowing __builtin_uadd_overflow didn't overflow
https://bugs.llvm.org/show_bug.cgi?id=45688
Bug ID: 45688
Summary: Missed optimization on comparison after knowing
__builtin_uadd_overflow didn't overflow
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
bool f(unsigned a, unsigned b)
{
unsigned result;
bool overflowed = __builtin_uadd_overflow(a, b, &result);
__builtin_assume(!overflowed);
return result >= b;
}
This can be optimized to `return 1;`. This transformation is done by GCC, but
not by LLVM.
Comparison here : https://godbolt.org/z/i44m2a
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45689] New: Failure to optimize away range check of modulo based on known ranges
https://bugs.llvm.org/show_bug.cgi?id=45689
Bug ID: 45689
Summary: Failure to optimize away range check of modulo based
on known ranges
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b)
{
assume(a > -4);
assume(b > -6 && b < 10);
int c = a % b;
return c >= -3 && c <= 8;
}
This can be optimized to `return true;`. This transformation is done by GCC,
not by LLVM.
Comparison here : https://godbolt.org/z/hnYFTA
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45690] New: Slow code (-O2) due to using jne instead of using cmove
https://bugs.llvm.org/show_bug.cgi?id=45690 Bug ID: 45690 Summary: Slow code (-O2) due to using jne instead of using cmove Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: levo.delel...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23403 --> https://bugs.llvm.org/attachment.cgi?id=23403&action=edit The test cpp file I attached my test file. I compiled with clang -O2 test.cpp -S I notice branching in my code when I specifically wrote it so it wouldn't branch. It jumped over a single instruction so I replaced it with a cmove. It appears to cut this loop time in half 95,97c95 < jne .LBB1_8 < # %bb.7:# in Loop: Header=BB1_6 Depth=1 < movl%ecx, %edx --- > cmove %ecx, %edx 105,107c103 < jne .LBB1_10 < # %bb.9:# in Loop: Header=BB1_6 Depth=1 < movl%ecx, %edx --- > cmove %ecx, %edx 115,117c111 < jne .LBB1_12 < # %bb.11: # in Loop: Header=BB1_6 Depth=1 < movl%ebx, %edx --- > cmove %ebx, %edx 125,127c119 < jne .LBB1_14 < # %bb.13: # in Loop: Header=BB1_6 Depth=1 < movl%ecx, %edx --- > cmove %ecx, %edx 135,137c127 < jne .LBB1_16 < # %bb.15: # in Loop: Header=BB1_6 Depth=1 < movl%ebx, %edx --- > cmove %ebx, %edx 145,147c135 < jne .LBB1_18 < # %bb.17: # in Loop: Header=BB1_6 Depth=1 < movl%ecx, %edx --- > cmove %ecx, %edx 155,157c143 < jne .LBB1_20 < # %bb.19: # in Loop: Header=BB1_6 Depth=1 < movl%ebx, %edx --- > cmove %ebx, %edx 165,167c151 < jne .LBB1_22 < # %bb.21: # in Loop: Header=BB1_6 Depth=1 < movl%ecx, %edx --- > cmove %ecx, %edx -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
