On 11/9/21 7:29 AM, Jakub Jelinek wrote:
> On Tue, Nov 09, 2021 at 01:03:38PM +0100, Richard Biener wrote:
>>> Apparently the range_of_expr can handle some tree cases through
>>> range_query::get_tree_range, like INTEGER_CSTs, ADDR_EXPRs,
>>> and some binary and unary ops.
>> But that shouldn't need a range query object ... this was all
>> available pre-ranger and just got stuffed there for no good reason?
resolving the binary ops requires calls back into range_of_expr to 
resolve operands.  It could be split out if needed/desired.
> That is for Andrew/Aldy to answer.
> All I can say is that get_tree_range is a non-static member function
> of range_query and therefore it needs non-NULL query object.
>
> But I must say I wonder if all this pain is worth it, if it wouldn't
> be easier to keep cfun->x_range_query NULL most of the time and use
> ATTRIBUTE_RETURNS_NONNULL inline range_query *
> get_range_query (const struct function *fun)
> {
>    return fun->x_range_query ? fun->x_range_query : &global_ranges;
> }
>
> (of course, the function then would need to be in some header
> where global_ranges is declared).
>
> 	Jakub
>
Yeah, Im not particular about how we do this...  I think thats perfectly 
reasonable.   Would something like the following solve this issue?

It creates a global-range class pointer, initializes it to point to the 
global query, and we can simply hide its existence and refer to it 
directly from function.h if you thinks thats reasonable and will work OK 
for this.   Then we dont have any inclusion issues.

Let me know and I'll run it thru the gauntlet.

Andrew