[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pip Cet
Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers
Date: Sat, 29 Jun 2019 05:44:22 +0000

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

> > > (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]