This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better
- From: Michael Matz <matz at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 4 Dec 2017 22:25:53 +0100 (CET)
- Subject: Re: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better
- Authentication-results: sourceware.org; auth=none
- References: <f1e10f4b-dd84-a39b-8561-856a9a14ffd7@redhat.com>
Hi,
On Thu, 30 Nov 2017, Jeff Law wrote:
> And after PHI propagation we have:
> # m_5 = PHI <10(5), 12(6), 14(7)>
> # _2 = PHI <10(5), 12(6), 14(7)>
> # _3 = PHI <320(5), 384(6), 448(7)>
> <L13>:
> goto <bb 12>; [100.00%]
>
> DCE will come along and wipe out m_5 and _2 if they are unused.
When I did something along these lines a long time ago I had to be a bit
careful in not regressing performance. Every PHI node with constants will
generate N instructions (with N the arity), there's no coalescing
possible. And if the feeding PHI nodes don't go away it increases
register pressure by (at least) one.
In one situation at that time I basically replaced N PHI nodes and
N*N instructions (each calculating x op y for each x,y \in PHI) by N*N PHI
nodes, increasing register pressure unsensibly. As the N*N instructions
formed a few expr trees the register pressure before the transformation
was merely at about N+3. In the end the benchmark was 30% slower than
faster :) (spilling added)
(If I read the patch correctly you don't handle the situation of "x op y"
where both arguments come from PHI nodes, so it's probably not an issue
for you, but I thought I'd mention it)
Ciao,
Michael.