> 2023年4月21日 08:41，Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx> 写道： > > On Thu, Apr 20, 2023 at 08:29:03PM +0100, Jiaxun Yang wrote: >> Yes, GAS and LLVM sometimes have different opinions on what a instruction >> feature should belong to. Personally I think there is no right or wrong in most case. >> >> So generally when we try to use some inline assembly features that toolchain >> may consider belongs to higher ISA level we will use `.set mips64r2` directives. >> >> Having this patch just unified the defined arch across the tree, so it happens to fix >> some cases where `.set` was given a improper option. > > I'd prefer, if we don't magically fix something by doing this massive > replacement. So first bug fixing then cleanup. It really cost a fortune to identify all of those problems, while this is A one off fix for all potential problems. > > And what I don't like is the name of the #defines (I know it's not your > choice, ), they don't tell me anything and it's still not clear which > one should be used in which case. Perhaps MIPS_ISA_SUPERSET or something? > > I see one use case, which is enabling 64bit instruction inside a 32bit > kernel. > > What are the others ? Mostly enabling instructions that may not belong to current -march config. e.g.: MT/MSA requires R2 but sometimes we do want to compile in for R1 kernel. MFC0/MTC0 with sel oprand requires R1, but we are using it on earlier CPUs with sel = 0 or on some unreachable (only determined at runtime) paths. GAS is unhappy to assemble LLSC on some CPU variants, while we are going to detect if we can use LLSC on those systems at runtime. The same for wait and cache. There are just too many usage in kernel. > > Do we really need all of them ? For example the change in > arch/mips/mm/cex-oct.S, this is for a octeon kernel, which only supports > and works with 64bit kernels... I must admit by my visual inspection there is certainly some unnecessary .sets, sometimes they are blindly copied from else where. But identify them requires a lot of effort, i.e., build for all of our support CPUs with different ASE/Endian options. I’d leave this for a future clean-up. Thanks Jiaxun
