This is the mail archive of the
mailing list for the GCC project.
Re: TARGET_MACRO_FUSION_PAIR for something besides compare-and-branch ?
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 28 May 2014 17:47:16 +0100
- Subject: Re: TARGET_MACRO_FUSION_PAIR for something besides compare-and-branch ?
- Authentication-results: sourceware.org; auth=none
- References: <5385EF20 dot 2020209 at arm dot com> <alpine dot LNX dot 2 dot 00 dot 1405282017050 dot 7582 at monopod dot intra dot ispras dot ru>
On 28/05/14 17:36, Alexander Monakov wrote:
On Wed, 28 May 2014, Kyrill Tkachov wrote:
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
tell the scheduler that two insns should not be scheduled apart. It doesn't
specify what kinds of insns those can be.
Yet from what I can see in sched-deps.c it can only be used on compares and
conditional branches, as implemented in i386.
Please note that it's not only restricted to conditional branches, but also to
keeping the instructions together if they were consecutive in the first place
(i.e. it does not try to move a compare insn closer to the branch).
Doing it that way allowed to solve the issue at hand at that time without a
separate scan of the whole RTL instruction stream.
Say I want to specify two other types of instruction that I want to force
together, would it be worth generalising the TARGET_MACRO_FUSION_PAIR usage
to achieve that?
Thanks for the insight,
I'd say yes, but that would be the least of the problems; the more important
question is how to trigger the hook (you probably want to integrate it into
the existing scheduler dependencies evaluation loop rather than adding a new
loop just to discover macro-fusable pairs).
Yeah, I was afraid that would be the case.
You'll also have to invent
something new if you want to move non-consecutive fusable insns together if
they are apart.
Seems to me that TARGET_SCHED_REORDER would be a better fit for that.