This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Mark Mitchell wrote:
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. :-)

Well, I could do better:


/* Ignore stores to DECL_IGNORED variables, so we do not pessimize
   abstraction during inlining.  */

at least it tells the reason why we do this.  Of course not why it
achieves that (at least that isn't clear to me - but I'm new to gcc
and didn't invent all this stuff :)).

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.

Sorry, I don't see that (MODIFY_EXPR (VAR_DECL) (TARGET_EXPR)) is
related to the problem (due to the lack of understanding of the TARGET_EXPR tree code). The problem is that estimate_num_insns is
a per-statement and as such local operation - and the frontends
generate multiple statements for a function call - appearantly after
filtering out all stores to DECL_IGNORED reduce to one statement,
the CALL_EXPR. But I understand this is a requirement of GENERIC/GIMPLE.


Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]