Il 21/05/2012 19:49, Dimitrios Apostolou ha scritto:
Thanks for reviewing, in the meantime I'll try to figure out why this
patch doesn't offer any speed-up on ppc64 (doesn't break anything
though), so expect a followup by tomorrow.
Perhaps you hit this?
else if (GET_CODE (XEXP (note,
Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
+static void
+df_find_hard_reg_defs_1 (rtx *loc, basic_block bb,
+ int flags, HARD_REG_SET *defs)
BB and FLAGS are not needed here, I am changing this and rebootstrapping.
Paolo
On Tue, 22 May 2012, Paolo Bonzini wrote:
Il 21/05/2012 19:49, Dimitrios Apostolou ha scritto:
Thanks for reviewing, in the meantime I'll try to figure out why this
patch doesn't offer any speed-up on ppc64 (doesn't break anything
though), so expect a followup by tomorrow.
Perhaps you hit
Il 22/05/2012 18:26, Dimitrios Apostolou ha scritto:
You are right, and I noticed that if we reverse (actually put straight)
the loop for the PARALLEL defs inside df_defs_record() then the speedup
stands for both x86 and ppc64.
The following patch was tested on x86, do you think it is
On Tue, 22 May 2012, Paolo Bonzini wrote:
Il 22/05/2012 18:26, Dimitrios Apostolou ha scritto:
You are right, and I noticed that if we reverse (actually put straight)
the loop for the PARALLEL defs inside df_defs_record() then the speedup
stands for both x86 and ppc64.
The following patch
Hi Paolo,
On Mon, 21 May 2012, Paolo Bonzini wrote:
Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
Paolo: I couldn't find a single test-case where the mw_reg_pool was
heavily used so I reduced its size. You think it's OK for all archs?
Makes sense, we can see if something breaks.
Hello list,
I'm resubmitting this patch from last year's GSOC which speeds up
compilation by avoiding thousands of calls to qsort(). Measured again it's
impact on compilation speed, this time compiling (cc1) gcc's reload.c on
i386:
orig: 0.734s
patched:0.720s
Tested on
