public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/42436] New: VRP should mark non-trapping integer divisions
@ 2009-12-19 19:41 rguenth at gcc dot gnu dot org
2009-12-19 19:42 ` [Bug tree-optimization/42436] " rguenth at gcc dot gnu dot org
0 siblings, 1 reply; 4+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-12-19 19:41 UTC (permalink / raw)
To: gcc-bugs
In PR42108 a division is found to be non-trapping by VRP but neither PRE nor
LIM can make use of that information (well, because VRP doesn't mark the
divisions in any meaningful way).
--
Summary: VRP should mark non-trapping integer divisions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 42108
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <bug-42436-4@http.gcc.gnu.org/bugzilla/>]
* [Bug tree-optimization/42436] VRP should mark non-trapping integer divisions
[not found] <bug-42436-4@http.gcc.gnu.org/bugzilla/>
@ 2022-01-12 16:14 ` amacleod at redhat dot com
2022-01-13 7:13 ` rguenth at gcc dot gnu.org
1 sibling, 0 replies; 4+ messages in thread
From: amacleod at redhat dot com @ 2022-01-12 16:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
What needs to be done here? anything?
Looking at VRP1, there is only a single divide left at that point:
countm1.6_54 = _12 / _13;
and VRP1 is setting the global range of _13 to:
_13: unsigned int [2, 2147483647]
So at least from that point on, it is trivial to determine the divide is
non-trapping even using the global ranges.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/42436] VRP should mark non-trapping integer divisions
[not found] <bug-42436-4@http.gcc.gnu.org/bugzilla/>
2022-01-12 16:14 ` amacleod at redhat dot com
@ 2022-01-13 7:13 ` rguenth at gcc dot gnu.org
1 sibling, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-13 7:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think this was trying to cover things like
if (d != 0)
tem = a / d;
where the non-zero range of d on the division cannot be put in global ranges
for its SSA name since that would be incorrect for uses not guarded by the
condition. So it would ask for a new flag on GIMPLE statements to mark the
division not trapping (like we have TREE_THIS_NOTRAP). Transforms like
PRE or LIM that do code motion of course have to be careful to not move
the stmt outside of the condition that made it not trapping - something which
would be as hard to guarantee as computing the non-trappingness in the first
place.
So yes, the case that made me file this bug is fixed with global ranges.
Let's close this bug since it's quite unspecific.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-01-13 7:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-19 19:41 [Bug tree-optimization/42436] New: VRP should mark non-trapping integer divisions rguenth at gcc dot gnu dot org
2009-12-19 19:42 ` [Bug tree-optimization/42436] " rguenth at gcc dot gnu dot org
[not found] <bug-42436-4@http.gcc.gnu.org/bugzilla/>
2022-01-12 16:14 ` amacleod at redhat dot com
2022-01-13 7:13 ` rguenth at gcc dot gnu.org
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).