Re: Supporting “crippled” MIPS implementations as cpu option

[Gabriel Ravier]

On 3/6/25 3:07 PM, mzpqnxow via Gcc wrote:
> Hello,
>
> Direct questions listed at the end for the impatient :)
>
> Hopefully my mail client wraps the text properly, if not, I apologize in
> advance. I haven’t used this client for mailing list posts before…
>
> I’m looking for information on GCC patch submission, hoping someone can
> provide some guidance. Specifically, the formal or informal guidelines used
> when determining if a specific submission is, in principle, something that
> is welcomed, assuming it meets technical guidelines. I do not want to send
> a patch if it won’t be considered as I don’t want to waste developers’ time
>
> What I’m talking about: I would like to understand how open the project is
> to accepting small patches that add support for a CPU (-mcpu targets) when
> they’re very slight variations within a supported architecture
>
> Why: I have the occasional need to have gcc emit MIPS1 instructions that do
> not contain a subset of loads and stores (lwl/swl/lwr/swl instructions)
>
> Context/History: There are several patches floating around that do this,
> primarily from developers working on embedded networking development on a
> few Realtek SoCs in the rtl819x family. These CPUs do not support these
> instructions due to patent issues, and will SIGILL when encountering them.
> I’m not aware of any work to contribute these upstream after a few quick
> searches. There is extensive information available on OpenWRT [1]
>
> Some specific questions:
>
> 1. Are any gcc mips experts aware of a way to accomplish what I described
> above (no lwl/swl/lwr/swr instructions) *without* patching GCC? I have not
> yet tested -mno-struct-align/-mstrict-align though they sound promising. I
> plan to give them a try, it may render this all moot. I may be
> misunderstanding precisely what they do
> 2. Are these sorts of patches (mcpu target, unpopular architecture)
> generally considered currently?
> 3. If “it depends” - what are the primary considerations? Does the
> popularity of the target factor into it? I admit that this CPU is not
> popular and though it can still be found in embedded network devices, it is
> only getting less common
> 4. If such a patch produces code that is inherently incompatible with glibc
> (or some other core dependency of a common toolchain) is that considered a
> blocker? What I’m referring to here is a (theoretical) example where glibc
> uses the “bad” instructions in an asm block as part of some low-level
> component (iirc, sigsetjmp, some of the loader functionality, etc. uses
> hand-written asm)
>
> I understand this is a pretty niche thing, only benefitting a subset of GCC
> users, so I’m not expecting a lot of willingness to accept such a patch,
> despite its relatively simplicity. I’m appreciative of any advice, guidance
> or commentary the community has to offer, even if the answer is effectively
> “don’t bother” :)
>
> Thanks!
>
> 1. https://openwrt.org/docs/techref/hardware/soc/soc.realtek


I would generally expect/hope that such a patch would be relatively 
simple to accept, given that, unless I am gravely wrong about the 
meaning and functionality of the macro "ISA_HAS_LWL_LWR" in 
gcc/config/mips/mips.h, it seems like a patch should not actually 
involve much more than adjusting this macro (and adding some option for 
the corresponding CPUs, as you mentioned).