On Fri, 19 Feb 2021, YunQiang Su wrote: > > My understanding therefore is that the original assumption that `optimal' > > will serve people best is no longer true. > > > > I guess that `optimal' can still produce the best performance, while > the delay slot > make MIPS quite differnent with other architectures. > And the hardware engineers seems hate it also.
Right, but what does it have to do with compiler defaults? Given what we have available in hardware we want the best results possible, except for research or special use cases (such as GAS's `-minsn32' option with microMIPS code). I would like to understand what the use case is here. > And we expect that MIPS can have as few as possible differnece delta > with other major architectures, > to ultily all of new framworks of community. Well, machine code is inherently architecture-specific, so you can't have a single template that fits all. The difference betwen processor architectures is more than just the bit patterns for individual opcodes and operand encodings (and the corresponding mnemonics and syntax for the assembly language). For example one of the major architectures is ARM, which has conditions encoded with all the instructions. And you cant mimic it with other ISAs. Similarly Power has 8 sets of condition codes and dedicated instructions to make ALU operations between these codes. You can't do those elsewhere either. Well, the MIPS or RISC-V ISAs do not have condition codes at all. And x86 is not a load-store architecture at all, so you'll see operations made directly on memory, as a destination even (let's ignore the even more arcane original 32-bit instruction set). These are all considered major architectures nowadays. So we have got the MIPS ISA and its delay slots. Some subsets/variations of the ISA have already either greatly reduced their use or eliminated them completely, but we went into great lengths with GCC to produce good code making use of these delay slots, so I think it would be a shame to get this effort wasted on one hand, and MIPS code put at a disadvantage due to cycles wasted for pipeline stalls that could be avoided if delay slots were scheduled -- on the other. > > First, I think it would be good if we knew why. I find proliferating > > variants of defaults, especially for the less obvious cases, will cause > > user confusion as one won't know what code model to expect, especially as > > (please correct me if I am wrong) we don't actually provide a way to dump > > the compiler's overridable configuration defaults. > > > > So, should we provide a predefined macro for it? I've been thinking more along `gcc -v --version' dumping the invocation of `configure' used, but I have to correct myself here in that it already happens, so nothing to do. I'm not sure why I forgot it and/or could not have figured it out previously. Sorry about the confusion. > > Second, I wonder if it makes sense to just keep things simple, and rather > > than adding `prefer' (to stand for "`always' if available"), and possibly > > `avoid' (to stand for "`never' if available"), whether we shouldn't just > > relax the checks for `always' and `never', and let them through whether > > the architecture selected provides for the option chosen or not. > > > > relax the `always' is what I would like to do first. > But I was afread to break some complatiable. Hmm, honestly I don't think there could be any compatibility to care of here given that the compiler currently refuses to run with such an option combination. Nobody may have relied on that then and the extra protection given is in my opinion a bit excessive. Garbage in, garbage out: you get what you have requested. Our usual policy with irrelevant options has been to silently ignore them, which helps users override Makefile defaults by just having CFLAGS, etc. appended to whatever the defaults are. > > Please note that in the discussion quoted Catherine has already raised a > > concern I agree with of adding a complication here, and now we would > > complicate it even further by not only adding a fourth choice, but another > > overridable configuration default as well. > > I am still concern about whether we should just set the `always' as default. > My short team plan is to set it default for Debian r6 Port. > So, at least, I wish that we can provide a buildtime option for other need. You're free with what you do with your distribution, although it seems to me like it's going to be a performance regression. I suggest that you do some benchmarking with real code and hardware before you decide. Maybe you can prove me wrong and there will be no loss of any significance. Maciej
