On Fri, Jun 28, 2019 at 12:14 PM Bruno Haible <br...@clisp.org> wrote:
> Pip Cet wrote:
> > This makes it safe to use function expressions in eassume, whether the
> > function is inlined or not.
>
> By "safe" you mean that you want the function call to not be evaluated.
Sorry, sloppy wording there. You're right.
> You are mentioning a limitation:
>
> > eassume(i >= 0 && i < complicated_function ());
> >
> > will not "split" the && expression, so it'll behave differently from
> >
> > eassume(i >= 0);
> > eassume(i < complicated_function ());
>
> And I would mention a regression: When -flto is in use and the expression
> invokes an external potentially-inlined function, the old 'assume' would
> work fine, i.e. do optimizations across compilation-unit boundaries.
Sorry, can't reproduce that here. I'm sure the changes I need to make
are obvious once I've found them, but can you let me know your gcc
version?
> > But even in those cases, this approach is better than the old approach
> > of actually evaluating complicated_function.
>
> I disagree that it is better:
Sorry to be pedantic, but do you disagree that it is better in these
cases, or in general? The latter is a question that I'm trying to find
the answer to, but in these specific cases, it clearly is better.
(Just in the interest of full disclosure, I described the idea in a
different context; I think it's a neat hack, and I'm trying to figure
out whether it has practical applications, but if it doesn't then I
won't feel there's continuing disagreement).
> 1. The new 'assume' is worse when -flto is in use.
Maybe. Even if it is, though, that's a GCC limitation which I consider
likely to be fixable; your estimation of that may vary, of course.
> 2. You recommend to users to split assume(A && B) into assume(A); assume(B);
> which is unnatural.
I make that recommendation independently of which assume is in use.
In practice, combining a complicated expression with a simple one in
an eassume is almost always not what you want to do. It's way too easy
to do something like
eassume(ptr->field >= 0 && f(ptr));
when what you mean is
eassume(ptr->field >= 0);
eassume(f(ptr));
(As an unusual special case, consider:
{
printf("%d\n", i & 0x80000000);
assume(i >= 0 && complicated_function());
}
which would generate different code from
{
printf("%d\n", i & 0x80000000);
assume(i >= 0);
assume(complicated_function());
})
Combining two simple expressions and not getting the right result
appears, at this point, to run into a GCC limitation, but I'm not sure
where.
> > At first, I thought it would be better to have a __builtin_assume
> > expression at the GCC level, but even that would have to have "either
> > evaluate the entire condition expression, or evaluate none of it"
> > semantics.
>
> No. At GCC level, it could have a "make the maximum of inferences - across
> all optimization phases -, but evaluate none of it" semantics.
There's no contradiction there: I'm saying that the programmer is
allowed to assume that the expression passed to assume either has been
evaluated, or hasn't been, with no in-between interpretations allowed
to the compiler. That means assume (A && B) isn't equivalent, in
general, to assume (A); assume (B); My suspicion is that the latter is
almost always what is intended.
