This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] MIPS: Fix PR33479 Broken atomic memory primitives.
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