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: [RFC] hard-reg-set.h refactoring

From: Dimitrios Apostolou <jimis at gmx dot net>
To: Paolo Bonzini <bonzini at gnu dot org>
Cc: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>
Date: Mon, 1 Aug 2011 18:57:46 +0300 (EEST)
Subject: Re: [RFC] hard-reg-set.h refactoring
References: <alpine.LNX.2.02.1107302005400.1374@localhost.localdomain> <CAHFMJ7uB5m5bEGb0JPMm=YbnEmEkQyY9zpn_K87aUhVP1So+kw@mail.gmail.com>

On Sun, 31 Jul 2011, Paolo Bonzini wrote:

On Sat, Jul 30, 2011 at 19:21, Dimitrios Apostolou <jimis@gmx.net> wrote:

Nevertheless I'd appreciate comments on whether any part of this patch is
worth keeping. FWIW I've profiled this on i386 to be about 4 M instr slower
out of ~1.5 G inst. I'll be now checking the profiler to see where exactly
the overhead is.


I suggest -fdump-tree-all too, to check if unrolling is happening and
if not why.

I don't fully understand the output from -fdump-tree-all, but my conclusion based also on profiler output and objdump, is that both unrolling and inlining is happening in both versions. Nevertheless I can see that assembly output is a bit different in the two cases (I can post specific disassembly output if you are interested).

My opinion is that code cleanup is worth the minor overhead, given that there should be no regressions.


Thanks,
Dimitris

Follow-Ups:
- Re: [RFC] hard-reg-set.h refactoring
  - From: Paolo Bonzini

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