Re: [PATCH] [4.0] Fix performance regressions due to inlining

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:

> I see patch one as the mosts important - maybe not the approach, but
> the result.  I.e. that we remove the abstraction penalty.  I tried to do
> this by only mucking with the RETURN_EXPR handling, but did not
> succeed, because we have an extra copy here in the caller, too.  I tried
> to account for this, but that didn't work.  Ignoring nodes that don't result
> in code generation (aka, effectively counting what TER would give us
> before RTL expansion) did produce size estimates more similar to the 3.4
> ones, and - magically - solved the abstraction problem.  "Magically"
> to me - but it looks appealing because of the simplicity of the patch.

The problem is that this comment:

  /* This is magic.  */
  ...

in the source code will not be particularly instructive to future 
generations of developers. :-)

> Do you have a better idea to address the abstraction problem for 4.0?

I think that the right solution is going to involve improving the 
instruction-estimation to account for the kinds of phenomenon that 
you're observing.  Like, find where we have (MODIFY_EXPR (VAR_DECL) 
(TARGET_EXPR)) and realize that this will (probably) be free, because 
the TARGET_EXPR will actually result in assignment to the VAR_DECL.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304