On Fri, Jun 28, 2019 at 11:30 PM Bruno Haible <br...@clisp.org> 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.
