This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with reload bug, please

On 01/23/15 14:46, Andrew Stubbs wrote:

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.
You have to be conservative here. It's part of the fundamental design issue you're trying to work around.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]