[Patch] MIPS: Fix PR33479 Broken atomic memory primitives.

Richard Sandiford rsandifo@nildram.co.uk
Thu Sep 27 04:08:00 GMT 2007


Nigel Stephens <nigel@mips.com> writes:
> Richard Sandiford wrote:
>>  The processors chosen for
>> -mips32, -mips32r2 and -mips64 are all on your list of targets that
>> benefit from branch-likely instructions, but given that the instructions
>> seem to be a win for more implementations than not, I think it'd make
>> sense to keep those mappings, even with the newly-enabled instructions.
>>   
>
> Hmm, I'm not so sure. We'd probably like a generic MIPS32 Linux 
> userland, say, to give decent performance across a range of cores. 
> Although the strict deprecation may be removed, the performance impact 
> of using branch likely on processors which predict branch likely as 
> "always taken" would be severe. That's certainly true for the 20K, but 
> might be true on other vendors' implementations of the MIPS32 ISA too.
>
> What we did in gcc-3.4 was detach some of these code generation options 
> from the processor type used for tuning: the mips_cpu_info table gained 
> an extra flag word which allowed you to specify defaults like: 
> enable/disable branch likely, hard/soft float, ASEs implemented, etc. 
> That way -march=mips32 entry could disable branch-likely, while 
> -march=24kc enabled it. Is there any value in adding something like that?

Well, I certainly have no objection to mips_cpu_info table spawning
an extra field for tuning information, and yeah, I agree it might
be the best way of resolving the branch-likely tuning.  (As you know,
the hard/soft-float choice is the only one of the three things in your
list to be implemented in mainline, and I still think that the way we
ended up doing this -- namely DRIVER_SELF_SPECS -- is better, because
it automatically picks the right multilibs.)

I'll try to come up with a patch in the next few days.

Richard



More information about the Gcc-patches mailing list