[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151

--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #19)

> 
> While ranger has a range_on_exit API this doesn't work on GENERIC expressions
> as far as I can see but only SSA names but I guess that could be "fixed"
> given range_on_exit also looks at the last stmt and eventually defers to
> range_of_expr (or range_on_entry), but possibly get_tree_range needs
> variants for on_entry/on_exit (it doesn't seem to use it's 'stmt' context
> very consistently, notably not for SSA_NAMEs ...).

That would appear to be an oversight. That API has not been used very much for
arbitrary generic trees.  I think the original reason support for tree
expressions was added was a "try this" for some other PR. It was simple to do
so we lef tit in, but it never got any real traction.  At least as far as I can
recall :-)

Currently, I think mosrt, if not all, uses of get_tree_range() are either
!gimple_ssa_range_p() (commonly constants or unsupported types) or ssa_names on
abnormal edges. 

For abnormal edges, we ought to be getting the global range directly these days
instad of calling that routine.   Then in get_tree_range (), we ought to be
calling range_of_expr for SSA_NAMES with the provided context.  I'll poke at
that too. The support for general tree expressions changed the original intent
of the function, and it should be adjusted. 

As for the on-exit/on-entry bits... we haven't had a need for entry/exit
outside of ranger in the past.  I had toyed with exporting those routines and
making them a part of the official API for value-query, but hadn't run across
the need as yet.

Let me think about that for a minute. It can certainly be done. I guess we
really only need an on-entry and on-exit version of range_of_expr to do
everything.  So if we end up with something like:  
  range_of_expr (r, expr, stmt)
  range_of_expr_on_entry  (r, expr, bb)
  range_of_expr_on_exit (r, expr, bb)

And have that all work with general trees expressions.. That would solve much
of this for you?



> 
> Interestingly enough we somehow still need the
> 

> 
> hunk of Andrews patch to do it :/
> 

That probably means there is another call somewhere in the chain with no
context. However, I will say that functionality is more important than it
seems. Should have been there from the start :-P.