This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Evgeny Stupachenko <evstupac at gmail dot com>
- Cc: Vlad Makarov <vmakarov at redhat dot com>, Uros Bizjak <ubizjak at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 14 Oct 2014 10:43:45 -0600
- Subject: Re: [PATCH 1/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code
- Authentication-results: sourceware.org; auth=none
- References: <CAOvf_xwaSa3++A31O56FqfW_LQsNfAtBTpwZ-3d+XXAiuf03Yw at mail dot gmail dot com> <5438035A dot 1030408 at redhat dot com> <20141014130051 dot GB10376 at tucnak dot redhat dot com>
On 10/14/14 07:00, Jakub Jelinek wrote:
That works for me -- I've been encouraging Intel to push emitting the
PIC setup further and further back in the RTL pipeline. Their early
patches had it very early in the RTL pipeline and naturally there was
fallout/bleedout in various places in the optimizers.
For the first two, I think (and said it before already) that the current
model of emitting set_got from a target hook during RA can't work, as there
can be calls in the prologue, and the prologue is inserted before the
set_got in that case. I really think the RA should in that case just tell
the backend whether and in which register it wants to have the PIC register
loaded upon start of the function, and it should be emit prologue pass
that should arrange for that.
I don't see much value in emitting the PIC setup prior to allocation,
all I see is problems.
RA improvements are the way to go -- however, my understanding is that
overall the code is better now than it was before Intel's changes, so I
don't consider the performance side as a blocker for this code.
As for the code quality, either some RA improvements are needed, or
postreload must be able to fix it up, or hardreg propagation (though,
cprop_hardreg is forward propagation rather than backwards, right?).
Better before prologue is emitted though, because that will save/restore
the badly chosen hard reg too.
The biggest performance issue identified so far is rematerialization.
The initial patch Intel sent to me was totally unacceptable as it just
hacked off optimizers rather than digging into the guts of why IRA/LRA
was unable to sanely rematerialize the PIC register value.