This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Early jump threading
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Andrew Pinski <pinskia at gmail dot com>, Jeff Law <law at redhat dot com>, "Richard Biener" <rguenther at suse dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>, <nd at arm dot com>
- Date: Tue, 18 Oct 2016 16:55:11 +0100
- Subject: Re: Early jump threading
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <20160811140235.GA68714@kam.mff.cuni.cz> <alpine.LSU.2.11.1608111604411.26629@t29.fhfr.qr> <20160811142700.GA57561@kam.mff.cuni.cz> <9B0D3D88-1653-4CB6-89BB-948064048D8F@suse.de> <b8460334-c8e3-ae84-083c-7fd6d57422fe@redhat.com> <20160918184850.GB58387@kam.mff.cuni.cz> <CA+=Sn1nTzbLmkHzwbT_kqgLH5RURHX0kvzM2bvp1q3AnDbcksw@mail.gmail.com> <20160919092227.GB354@kam.mff.cuni.cz>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Mon, Sep 19, 2016 at 11:22:27AM +0200, Jan Hubicka wrote:
> > On Mon, Sep 19, 2016 at 2:48 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > > Hi,
> > > this is the patch compensating testsuite I commited after re-testing
> > > on x86_64-linux.
> > >
> > > Other placements of early_thread_jumps does not work veyr well (at least in
> > > current implementation). Putting it before forwprop disables about 15% of
> > > threadings. Placing it after DCE makes inliner to not see much of benefits
> > > because threading requires a cleanup propagation+DCE after itself.
> > > So unless we extend threader to be smarter or add extra DCE cleanup, i think
> > > this is best placement.
> >
> >
> > This caused (another) 3-4% degradation in coremarks on ThunderX.
>
> Hmm, this is interesting. The patch should have "fixed" the previous
> degradation by making the profile correct (backward threader still doe not
> update it, but because most threading now happens early and profile is built
> afterwards this should be less of issue). I am now looking into the profile
> update issues and will try to check why coremarks degrade again.
But, the early threader is running with speed_p set to false (second parameter
to find_jump_threads_backwards)
unsigned int
pass_early_thread_jumps::execute (function *fun)
{
/* Try to thread each block with more than one successor. */
basic_block bb;
FOR_EACH_BB_FN (bb, fun)
{
if (EDGE_COUNT (bb->succs) > 1)
find_jump_threads_backwards (bb, false);
}
thread_through_all_blocks (true);
return 0;
}
So even though profile information is ignored, we think we are compiling
for size and won't thread. The relevant check in profitable_jump_thread_path
is:
if (speed_p && optimize_edge_for_speed_p (taken_edge))
{
<snip>
}
else if (n_insns > 1)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "FSM jump-thread path not considered: "
"duplication of %i insns is needed and optimizing for size.\n",
n_insns);
path->pop ();
return NULL;
}
Changing false to true in the above hunk looks like it enables some of
the threading we're relying on here.
Thanks,
James