This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.


In message <Pine.LNX.4.44.0403080926120.32121-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >> Well, the range bounds stuff is currently designed to only handle
 >> integers, not floats.    There's a lot of interesting issues when you
 >> start looking at handling floats -- NaNs come immediately to mind.
 >>
 >> The existing range should be considered a placeholder -- ultimately the
 >> range stuff should be largely done in the CCP engine since that engine
 >> can do a significantly better job at building range information (and
 >> probably do it more efficiently than we could in DOM).
 >
 >As hinted in my mail, my interest in range bounds at the moment is
 >as an extremely local property.
Understood.

 > We should in theory be able to
 >optimize "(x & 5) < 12" or "max (x, 6) < 4" during constant folding
 >without knowing anything about the range of values of actually held
 >in x. 
Definitely not a job for DOM.  These kinds of expressions are not gimple
and are not something you're ever going to see/optimize in DOM.

The only way you're going to see these kinds of expressions in the SSA
optimizers is via tree-combining, which we do very very very little of
right now.  We will one day, but certainly not right now.  And tree-combining
and tree-reassociation need to be their own passes independent of DOM, CCP,
etc.

This does point out an issue Richard and I recently discussed.  Namely that
range information needs to be a property attached to the SSA_NAME node,
not some on-the-side table.  That way it could be computed by DOM, CCP,
whatever, and optimizers that can use the information (such as the tree
combiner) can look it up when they need it.

 > As a first approximation, any unrecognized tree node can be
 >ascribed bounds TYPE_{MIN,MAX}_VALUE (TREE_TYPE (expr)).
We already do that to a limited extent in the dominator optimizer.
[ Limited because most of the time this range information is not useful
  and it just slows you down to compute it for every variable. ]


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]