This is the mail archive of the
mailing list for the GCC project.
Re: Help with reload bug, please
- From: Jeff Law <law at redhat dot com>
- To: Andrew Stubbs <ams at codesourcery dot com>, gcc at gcc dot gnu dot org, joern dot rennecke at embecosm dot com
- Date: Mon, 26 Jan 2015 13:00:03 -0700
- Subject: Re: Help with reload bug, please
- Authentication-results: sourceware.org; auth=none
- References: <54C2509C dot 2050908 at codesourcery dot com> <54C27811 dot 8040207 at redhat dot com> <54C2C141 dot 4070608 at codesourcery dot com>
On 01/23/15 14:46, Andrew Stubbs wrote:
You have to be conservative here. It's part of the fundamental design
issue you're trying to work around.
SECONDARY_INPUT_RELOAD_CLASS is another missed opportunity. Just like
the legitimate address stuff, this has checks for the various VFP
classes, but reload detects the class in the same flawed way, so an
integer reload gives GENERAL_REGS even when the destination is VFP.
Within the macro there's no way to see the whole insn.
We may have used special constraints as well to allow loads/stores of
integer registers in FP modes to use the larger offset.
Do you have an example?
The entire PA port? :-)
Note this was a huge issue on the PA because integer multiply was
implemented in the FP unit, so we regularly had integer mode accesses to
FP registers. If you don't have similar needs, I think there's some
further macros you can define to discourage that behaviour. I just
can't remember what they are.
I'd focus on the bits that determine that an address is legitimate or
not and the secondary reload mechanism.
Also note that the allowed offsets were increased in the PA 2.0 so you
have to filter out that while you're reading.