Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Pip Cet]

On Fri, Jun 28, 2019 at 11:30 PM Bruno Haible <address@hidden> wrote:
> Pip Cet wrote:
> > have started believing the "an inline function is as fast as a macro"
> > mantra*, assuming you include inline functions with "function calls".
>
> Ah, that's where the entire topic with the function calls inside assume()
> comes from! I agree it's an important case (more important than the
> functions defined in other compilation units).

As I said earlier:

----
This makes it safe to use function expressions in eassume, whether the
function is inlined or not.

(That GCC doesn't actually do very much with this information is a
separate issue).
----

So we're talking about this separate issue now? I ask not for
rhetorical points, but because I genuinely think it's interesting if
the objection is based on GCC limitations rather than fundamentally
unfixable reasons.

> So, the main effect of the proposed new 'assume' is that it de-optimizes
> the case where the CONDITION is defined using inline functions!

(I don't think it's the "main" effect).

That certainly is something that appears to be happening in some
situations. It's a GCC limitation, and let's be clear: as long as this
limitation isn't lifted, an inline function is not as fast as a macro.

However, passing an inline function to assume() is problematic anyway,
unless it's marked as __attribute__((always_inline)), and marking it
as __attribute__((always_inline)) is problematic because it might
directly contradict what the programmer was trying to achieve by
passing -fno-inline.

> Based on these results, I formally object against the proposed patch.

I won't argue against that as long as I haven't found a way around the
GCC issue, but I would like to state that the current assume does
behave very badly when combined with -fno-inline-small-functions
-fno-inline.

> > > (2) that the generated code will never include these function calls,
> > >     because the generated code with the 'assume' invocation should be
> > >     optimized at least as well as the generated code without the
> > >     'assume' invocation.
> >
> > I think it should be the rarest of exceptions for an assume() to
> > result in slower code, yes. I believe that includes the case where
> > functions marked inline aren't inlined, because of compiler options,
> > for example.
>
> Then, I think we should change the documentation of 'assume' to say
> that when it invokes functions, these functions should be marked
> '__attribute__ ((__always_inline__))', otherwise performance will
> be worse than without the 'assume', not better.

I disagree. It's tedious, and people might just change their INLINE
macros (or whatever) to specify __attribute__((always_inline)), making
-fno-inline worthless...

> > I think there's a significant probability that the GCC people would
> > agree to add such a built-in, but insist on its having "may or may not
> > evaluate its argument" semantics.
>
> We can tell them that it would be important for us that is does not
> evaluate its argument. Like sizeof (EXPRESSION) does not evaluate EXPRESSION.

We can tell them that, but my suspicion is it'll be much, much harder
to implement that way.