Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

[Andrew MacLeod <amacleod@redhat.com>]

On 10/13/22 05:53, Jakub Jelinek wrote:
> On Thu, Oct 13, 2022 at 08:11:53AM +0000, Richard Biener wrote:
>> On Wed, 12 Oct 2022, Andrew MacLeod wrote:
>>
>>> On 10/12/22 10:39, Jakub Jelinek wrote:
>>>> On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote:
>>>>> I presume you are looking to get this working for this release, making the
>>>>> priority high? :-)
>>>> Yes.  So that we can claim we actually support C++23 Portable Assumptions
>>>> and OpenMP assume directive's hold clauses for something non-trivial so
>>>> people won't be afraid to actually use it.
>>>> Of course, first the posted patch needs to be reviewed and only once it gets
>>>> in, the ranger/GORI part can follow.  As the latter is only an optimization,
>>>> it can be done incrementally.
>>> I will start poking at something to find ranges for parameters from the return
>>> backwards.
>> If the return were
>>
>>    if (return_val)
>>      return return_val;
>>
>> you could use path-ranger with the parameter SSA default defs as
>> "interesting".  So you "only" need to somehow interpret the return
>> statement as such and do path rangers compute_ranges ()
> If it was easier for handling, another possible representation of the
> assume_function could be not that it returns a bool where [1,1] returned
> means defined behavior, otherwise UB, but that the function returns void
> and the assumption is that it returns, the other paths would be
> __builtin_unreachable ().  But still in both cases it needs a specialized
> backwards walk from the assumption that either it returns [1,1] or that it
> returns through GIMPLE_RETURN to be defined behavior.  In either case,
> external exceptions, or infinite loops or other reasons why the function
> might not return normally (exit/abort/longjmp/non-local goto etc.) are still
> UB for assumptions.
> Say normally, if we have:
> extern void foo (int);
>
> bool
> assume1 (int x)
> {
>    foo (x);
>    if (x != 42)
>      __builtin_unreachable ();
>    return true;
> }
> we can't through backwards ranger walk determine that x_1(D) at the start of
> the function has [42,42] range, we can just say it is true at the end of the
> function, because foo could do if (x != 42) exit (0); or if (x != 42) throw
> 1; or if (x != 42) longjmp (buf, 1); or while (x != 42) ; or if (x != 42)
> abort ();
> But with assumption functions we actually can and stick [42, 42] on the
> parameters even when we know nothing about foo function.
>
> Of course, perhaps initially, we can choose to ignore those extra
> guarantees.
>
I dont think we need to change anything.  All I intend to do is provide 
something that looks for the returns, wire GORI in, and reuse a global 
range table in to a reverse dependency walk to starting with a range of 
[1,1] for whatever is on the return stmt.

 From GORIs point of view, thats all outgoing_edge_range_p () does, 
except it picks up the initial value of [0,0] or [1,1]  from the 
specified edge instead.

Initially It'll stop at the top of the block, but I don't think its too 
much work beyond that provide "simple" processing of PHIs and edges 
coming into the block..  In the absence of loops it should be pretty 
straightforward.  "All" you do is feed the value of the phi argument to 
the previous block.  Of course it'll probably be a little more 
complicated than that, but the basic premise seems pretty straightforward.

The result produced would be vector over the ssa-names in the function 
with any ranges that were determined.   You could use that to more 
efficiently store just the values of the parameters somewhere and 
somehow associate them with the assume function decl.

I'll try to get to this shortly.

Andrew