public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/93917] VRP forgets range of value read from memory [not found] <bug-93917-4@http.gcc.gnu.org/bugzilla/> @ 2020-11-19 23:20 ` amacleod at redhat dot com 2022-11-03 19:30 ` amacleod at redhat dot com ` (2 subsequent siblings) 3 siblings, 0 replies; 4+ messages in thread From: amacleod at redhat dot com @ 2020-11-19 23:20 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #2 from Andrew Macleod <amacleod at redhat dot com> --- This seems to be a good place to bring up a question I have. What exactly do we want to with __builtin_unreachable across passes? Ranger was initially starting with the previously set globally known value, and I had to disable it for pr61034.C Basically, the routine was pre-optimized and inlined, and inlining sets the global range based on the output from the optimizations, and when ranger removed the code with the unreachable in it, the testcase failed. so void f(int n){ if(n<0)__builtin_unreachable(); } n has a global range of [0, +INF] Is that the basic point of this? Can we set the global range to that and eliminate the if? same thing for if(*n<0)__builtin_unreachable(); I see: _1 = *n_3(D); if (_1 < 0) goto <bb 3>; [INV] else goto <bb 4>; [INV] 2->3 (T) _1 : int [-INF, -1] 2->4 (F) _1 : int [0, +INF] =========== BB 3 ============ <bb 3> : __builtin_unreachable (); And we can know that _1 is [0, +INF] from then on. Can we kill all these unreachables() the first time we see them if we set the range appropriately? If not, at what point do we want to kill them? ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/93917] VRP forgets range of value read from memory [not found] <bug-93917-4@http.gcc.gnu.org/bugzilla/> 2020-11-19 23:20 ` [Bug tree-optimization/93917] VRP forgets range of value read from memory amacleod at redhat dot com @ 2022-11-03 19:30 ` amacleod at redhat dot com 2022-11-28 22:09 ` pinskia at gcc dot gnu.org 2023-09-19 15:11 ` amacleod at redhat dot com 3 siblings, 0 replies; 4+ messages in thread From: amacleod at redhat dot com @ 2022-11-03 19:30 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- Fixed by commit e7310e24b1c0ca67b1bb507c1330b2bf39e59e32 Author: Andrew MacLeod <amacleod@redhat.com> Date: Tue Oct 25 16:42:41 2022 -0400 Make ranger vrp1 default. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/93917] VRP forgets range of value read from memory [not found] <bug-93917-4@http.gcc.gnu.org/bugzilla/> 2020-11-19 23:20 ` [Bug tree-optimization/93917] VRP forgets range of value read from memory amacleod at redhat dot com 2022-11-03 19:30 ` amacleod at redhat dot com @ 2022-11-28 22:09 ` pinskia at gcc dot gnu.org 2023-09-19 15:11 ` amacleod at redhat dot com 3 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2022-11-28 22:09 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |13.0 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/93917] VRP forgets range of value read from memory [not found] <bug-93917-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2022-11-28 22:09 ` pinskia at gcc dot gnu.org @ 2023-09-19 15:11 ` amacleod at redhat dot com 3 siblings, 0 replies; 4+ messages in thread From: amacleod at redhat dot com @ 2023-09-19 15:11 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917 --- Comment #4 from Andrew Macleod <amacleod at redhat dot com> --- Note a slight change in expectation as a result of commit r14-4141-gbf6b107e2a342319b3787ec960fc8014ef3aff91 for PR 110080 Due to a memory load in the second case, we do not remove the unreachable call now as there may be a commoning opportunity later (via inlining in this case) in which this unreachable call may provide new information. The test case has been adjusted to current expectations where we leave this unreachable call and then remove it and set the global range in VRP2 instead. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-19 15:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-93917-4@http.gcc.gnu.org/bugzilla/> 2020-11-19 23:20 ` [Bug tree-optimization/93917] VRP forgets range of value read from memory amacleod at redhat dot com 2022-11-03 19:30 ` amacleod at redhat dot com 2022-11-28 22:09 ` pinskia at gcc dot gnu.org 2023-09-19 15:11 ` amacleod at redhat dot com
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).