On 06/27/14 02:29, Kyrill Tkachov wrote:
Hi all,
This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work
on more than just
compares and conditional branches for which it was initially designed
for (for x86).
There are some instructions in arm and aarch64 that can be fused
together when they're back to back in the instruction stream and I'd
like to use this hook to keep them together.
I'll post an implementation of TARGET_MACRO_FUSION_PAIR_P for arm and
aarch64 shortly...
Bootstrapped and tested on x86, aarch64-none-linux-gnu and
arm-none-linux-gnueabihf.
Ok for trunk?
2014-06-27 Ramana Radhakrishnan <ramana.radhakrish...@arm.com>
Kyrylo Tkachov <kyrylo.tkac...@arm.com>
* sched-deps.c (try_group_insn): Generalise macro fusion hook usage
to any two insns. Update comment.
Isn't this going to end up calling the x86 specific macro_fusion_pair_p
with a lot more insns than that function was previously prepared to handle?
In particular I'm concerned that the 2nd argument is going to be a
non-jumping insn a lot more often. Of particular concern is this code:
test_if = SET_SRC (pc_set (condjmp));
cond = XEXP (test_if, 0);
ccode = GET_CODE (cond);
if CONDJMP is not a JUMP_INSN, pc_set is going to return NULL and XEXP
(test_if, 0) will then fault.
I realize you bootstrapped on x86, but I suspect that whatever tuning
you need to enable to really exercise this code wasn't on.
I think you can deal with this by putting
if (!any_condjump_p (condjmp)) at the start of the x86 specific
macro_fusion_pair_p is sufficient to address this issue. It also
ensures that we don't do a lot of unnecessary work in that function.
From a general code structure standpoint, can you avoid this kind of
structure:
if (any_condjmp_p (insn))
{
...
goto succ;
}
else
{
...
goto succ
}
return
succ:
Can you structure so that you return for all the cases where you don't
want to set SCHED_GROUP_P from each arm? Or go ahead and duplicate the
SCHED_GROUP_P setting in each arm of the conditional.
jeff
