This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR42861, VTA] bind values to expressions upon MO_VAL_USE
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org, dave at hiauly1 dot hia dot nrc dot ca
- Date: Mon, 01 Feb 2010 15:19:42 -0800
- Subject: Re: [PR42861, VTA] bind values to expressions upon MO_VAL_USE
- References: <4B606A19.80008@redhat.com> <201001281950.o0SJoqe16769@lucas.cup.hp.com> <20100128201220.GI2817@tyan-ft48-01.lab.bos.redhat.com> <1264720932.3456.59.camel@hpsje.cup.hp.com> <20100128233733.GK2817@tyan-ft48-01.lab.bos.redhat.com>
- Reply-to: sje at cup dot hp dot com
On Fri, 2010-01-29 at 00:37 +0100, Jakub Jelinek wrote:
> So something like:
>
> static rtx
> pa_delegitimize_address (rtx orig_x)
> {
> rtx x = delegitimize_mem_from_attrs (orig_x);
> if (GET_CODE (x) == LO_SUM
> && GET_CODE (XEXP (x, 1)) == UNSPEC
> && XINT (XEXP (x, 1), 1) == UNSPEC_DLTIND14R)
> return XVECEXP (XEXP (x, 1), 0, 0);
> return x;
> }
>
> could do the job.
>
> Jakub
FYI: I am still working on this, I have a small test case that works
before the VTA checkin but fails with the VTA change plus Jakub's
function (when compiled with -O1 or -O2)
The test case is:
f(int n) {
int i;
double v[n];
for(i=0;i<n;i++)
v[i]=0;
}
main() {
f(100);
exit(0);
}
Before the change v is initialized by writing out %r0 (%r0 always has
zero in it):
std %r0,0(%r19) ; 84 *pa.md:3933/6 [length = 4]
After the changs v is initialized with this:
fldd 0(%r0),%fr22 ; 106 *pa.md:3933/8 [length = 4]
fstd %fr22,0(%r19) ; 84 *pa.md:3933/9 [length = 4]
Instead of writing out a zero [%r0] it is writing out the contents of
memory location zero [0(%r0)]and that causes a fault.
I am not sure if this is related to why some delegitimize_address
functions have the "if (MEM_P (x)) x = XEXP(x, 0)" code in them or not
but I tried adding that and it didn't seem to help. The delegitimize
routine is getting called, it is converting:
(lo_sum:DI (reg:DI 156)
(unspec:DI [
(symbol_ref/u:DI ("*L$C0000") [flags 0x2])
] 2))
into
(symbol_ref/u:DI ("*L$C0000") [flags 0x2])
Which seems like the right change. The investigation continues, if I
can't figure out something soon I will submit a bug report and put all
this info in there.
Steve Ellcey
sje@cup.hp.com