On Thu, Mar 6, 2025 at 7:14 AM mzpqnxow via Gcc <gcc@gcc.gnu.org> 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)
The GCC patch to provide an option not emit lwl/lwr/swl/swr should be easily.
Something like:
```
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index e224ade2a1a..c40cae1a530 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1191,7 +1191,8 @@ struct mips_cpu_info {
&& (MODE) == V2SFmode)) \
&& !TARGET_MIPS16)
-#define ISA_HAS_LWL_LWR (mips_isa_rev <= 5 \
+#define ISA_HAS_LWL_LWR (mips_isa_rev <= 5
\
+ && TARGET_LEFT_RIGHT \
&& (!TARGET_MIPS16 || ISA_HAS_MIPS16E2))
#define ISA_HAS_IEEE_754_LEGACY (mips_isa_rev <= 5)
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index e24565469d9..e9414765b06 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -214,6 +214,10 @@ mfix4300
Target Var(TARGET_4300_MUL_FIX)
Work around an early 4300 hardware bug.
+mleftright
+Target Var(TARGET_LEFT_RIGHT) Init(1)
+Emit the load/store left/right instruction if possible
+
mfp-exceptions
Target Var(TARGET_FP_EXCEPTIONS) Init(1)
FP exceptions are enabled.
```
Adding a configure option should not be hard too but I am leaving that
up to you.
Note the MIPS port is not giving much support and I suspect patches
for this will be accepted as shown above it is minor.
As far as inline-asm/asm that uses load/stores left-right, you are
going need to audit each package that you.
You could also in theory error out in GNU binutils as which can help.
Accepting a patch to both I suspect will be acceptable upstream
communities since there is little to no development on the MIPS
backends and they are only now used for embedded/legacy developement.
Thanks,
Andrew Pinski
>
> 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
