[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

2022-01-27 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

2014-12-19 Thread olegendo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #4 f

[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

2014-12-16 Thread tavianator at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308 --- Comment #3 from Tavian Barnes --- @Richard Biener: Yes the range for _16 could be [0, 4294967294]. Why can't VRP can't assume division by zero doesn't occur? If it can then it could say anything mod [a, b] fits in [0, b - 1]. That's a reas

[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

2014-12-15 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308 --- Comment #2 from Marc Glisse --- You would need symbolic ranges, b and ret are in [0,m-1]. And then you are using that very specific x86 instruction that divides 64 bits by 32 bits but only works if the result fits in 32 bits. It works here be

[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

2014-12-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308 --- Comment #1 from Richard Biener --- Not sure if your analysis is correct, but value-range propagation computes ret_4: VARYING ... _12: [0, 4294967295] _13: [0, 4294967295] _14: [0, 18446744065119617025] _15: [0, 4294967295] _16: [0, +INF] fo