RFC: [MIPS] Add an option to disable ldc1/sdc1
Fri Feb 15 01:29:00 GMT 2013
On Thu, Feb 14, 2013 at 5:23 PM, Maciej W. Rozycki
> On Thu, 14 Feb 2013, Richard Sandiford wrote:
>> What about 64-bit targets? We can sometimes access doubles using GPRs,
>> so on 64-bit targets we could end up using LD and SD to access a double
>> even when this option disables LDC1 and SDC1. I think we'd need to
>> patch the move patterns as well.
> As far as Linux is concerned -- which from the context of this
> consideration I infer is the case -- there is no issue, because unless an
> app has explicitly requested this feature to be disabled, with the use of
> the sysmips(2) FIXADE API (which of course hardly any does), all address
> error exceptions triggered by an unaligned memory access made with a CPU
> instruction are trapped by the kernel and the access emulated.
> However no such accesses are emulated when made with a coprocessor
> instruction, whether the FPU or CP2 or the legacy CP1 and CP3 units as
> supported by earlier processors. There was once a proposal to emulate FPU
> instructions as well, posted on the linux-mips mailing list here:
> -- but the MIPS/Linux maintainer rejected the idea. I have cc-ed Ralf on
> this reply in case he wanted to add something.
I would reject it also. I say just fix the webkit code and forget
about these patches to both the GCC and the kernel.
Webkit is breaking C/C++ alignment rules anyways so the code is
undefined. Just go and fix webkit. There is no reason why webkit
can't just be fixed and we can forget about these broken patches to
work around broken code.
> Of course an option to GCC to disable any such instructions may have some
> value to some people -- for bare-iron targets if nothing else -- but I
> fear this is going to end up with a lot of hassle with 64-bit ABIs or even
> just 64-bit FPU (-mabi=32 -mfp64) as individual halves of 64-bit registers
> are not addressable in the MIPS architecture (e.g. there's no LWHC1
> instruction), so you'll need to use scratch registers.
> Which is why I think any resources put into this effort would better be
> used to clean up such broken code and, perhaps more importantly, to
> educate people to write their programs properly in the first place.
> Writing portable code is really not a big deal, you just need to remember
> all the world is not x86 and apply a few simple rules.
More information about the Gcc-patches