This is the mail archive of the
mailing list for the GCC project.
Re: Enable EBX for x86 in 32bits PIC code
- From: Jeff Law <law at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc at gnu dot org, gcc-patches at gcc dot gnu dot org
- Cc: Evgeny Stupachenko <evstupac at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>, vmakarov at redhat dot com
- Date: Mon, 25 Aug 2014 11:30:21 -0600
- Subject: Re: Enable EBX for x86 in 32bits PIC code
- Authentication-results: sourceware.org; auth=none
- References: <CAOvf_xxsQ_oYGqNAVQ1+BW+CuD3mzebZ2xma0jpF=WfyZMCRCA at mail dot gmail dot com> <CAFiYyc1mFtTezkTJORmJJq+yht=qPSwiN7KDn19+bSuSdaqvMQ at mail dot gmail dot com> <CAOvf_xyeVeg2oB9Xxz8RMEQ6gyfJY5whd9s4ygoAAEaMU9efnA at mail dot gmail dot com> <20140707114750 dot GB31640 at tucnak dot redhat dot com> <CAMbmDYZV_fx0jxmKHhLsC2pJ7pDzuu6toEAH72izOdpq6KGyfg at mail dot gmail dot com> <20140822121151 dot GA60032 at msticlxl57 dot ims dot intel dot com>
On 08/22/14 06:21, Ilya Enkovich wrote:
Isn't this typically handled with secondary reloads? It's not an exact
match, but if you look at the PA port, you can see cases where we need
to have %r1 available when we rematerialize certain constants. Several
ports have secondary reloads that you may be able to refer back to. LRA
may handle things differently, so first check LRA's paths.
Such approach worked well on small tests but trying to run some
benchmarks we faced a problem with reload of address constants. The
problem is that when we try to rematerialize address constant or some
constant memory reference, we have to use pic_offset_table_rtx. It
means we insert new usages of a speudo register and alocator cannot
handle it correctly. Same problem also applies for float and vector
Rematerialization is not the only case causing new
pic_offset_table_rtx usage. Another case is a split of some
instructions using constant but not having proper constraints. E.g.
pushtf pattern allows push of constant but it has to be replaced with
push of memory in reload pass causing additional usage of
Yup. I think those would be handled the same way.