bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PA-RISC 2.0 fldw instruction (formats 43 and 44)


From: John David Anglin
Subject: Re: PA-RISC 2.0 fldw instruction (formats 43 and 44)
Date: Mon, 20 May 2002 00:52:27 -0400 (EDT)

> work, and I'm rather busy.  Should gcc be generating this code for
> hppa-linux in the first place?

It's not just linux.  Jeff is against it but I favour it (or at least
I did until I discovered the binutils problem).  Currently under hppa1.1,
either the value is copied to the stack and loaded with a short displacement
load, or the address is used.  If you try building gcc with "-mpa-risc-2-0",
you will currently get the ICE described here:
<http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01426.html>.

There is a problem with the xmpyu pattern.  However, even with fixing the
xmpyu pattern, I still end up with the following ICE:

stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -DIN_GCC    -g 
-O2 -mpa-risc-2-0 -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -DHAVE_CONFIG_H    -I. -If -I../../gcc/gcc 
-I../../gcc/gcc/f -I../../gcc/gcc/config -I../../gcc/gcc/../include 
../../gcc/gcc/f/data.c -o f/data.o
../../gcc/gcc/f/data.c: In function `ffedata_advance_':
../../gcc/gcc/f/data.c:655: insn does not satisfy its constraints:
(insn 2638 563 582 (set (reg:DI 70 %fr23 [332])
        (mem/f:DI (lo_sum:SI (reg/f:SI 4 %r4 [873])
                (symbol_ref:SI ("ffedata_arraysize_"))) [29 
ffedata_arraysize_+0 S8 A64])) 118 {*pa.md:3247} (nil)
    (nil))
../../gcc/gcc/f/data.c:655: Internal compiler error in 
reload_cse_simplify_operands, at reload1.c:8367

Thus, the same error appears in a different way.  Jeff thinks there may be
a problem in secondary_reload_class.  I'm fairly sure that the same
problem would appear with hppa1.1 with the right testcase.

We need to load SI mode into the FPR registers for the xmpyu insn.
The same movsi/movdi patterns are used for both GPR and FPR loads.
We use these patterns to handle lo_sums for GPR loads.  Thus, it
would be difficult to stop lo_sum mems from being inserted into
insns that eventually end up with a FPR as the destination register.

There isn't a rush in resolving this.  I'm going to be away most
of the week.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]