Excerpts from Segher Boessenkool's message of February 26, 2022 8:28 am: > On Fri, Feb 25, 2022 at 10:23:07AM +1000, Nicholas Piggin wrote: >> Excerpts from Segher Boessenkool's message of February 25, 2022 3:29 am: >> > On Thu, Feb 24, 2022 at 09:13:25PM +1000, Nicholas Piggin wrote: >> >> Excerpts from Arnd Bergmann's message of February 24, 2022 8:20 pm: >> >> > Again, there should be a minimum number of those .machine directives >> >> > in inline asm as well, which tends to work out fine as long as the >> >> > entire kernel is built with the correct -march= option for the minimum >> >> > supported CPU, and stays away from inline asm that requires a higher >> >> > CPU level. >> >> >> >> There's really no advantage to them, and they're ugly and annoying >> >> and if we applied the concept consistently for all asm they would grow >> >> to a very large number. >> > >> > The advantage is that you get machine code that *works*. There are >> > quite a few mnemonics that translate to different instructions with >> > different machine options! We like to get the intended instructions >> > instead of something that depends on what assembler options the user >> > has passed behind our backs. >> > >> >> The idea they'll give you good static checking just doesn't really >> >> pan out. >> > >> > That never was a goal of this at all. >> > >> > -many was very problematical for GCC itself. We no longer use it. >> >> You have the wrong context. We're not talking about -many vs .machine >> here. > > Okay, so you have no idea what you are talking about? Wow. Wrong context. It's not about -many. We're past that everyone agrees it's wrong. > The reason GCC uses .machine *itself* is because assembler -mmachine > options *cannot work*, for many reasons. We hit problems often enough > that years ago we started moving away from it already. The biggest > problems are that on one hand there are mnemonics that encode to > different instructions depending on target arch or cpu selected (like > mftb, lxvx, wait, etc.), and on the other hand GCC needs to switch that > target halfway through compilation (attribute((target(...)))). > > Often these problems were hidden most of the time by us passing -many. > But not all of the time, and over time, problems became more frequent > and nasty. > > Passing assembler -m options is nasty when you have to mix it with > .machine statements (and we need the latter no matter what), and it No it's not nasty, read the gas manual. -m specifies the machine and so does .machine. It's simple. > becomes completely unpredictable if the user passes other -m options > manually. > Inline assembler is inserted textually in the generated assembler code. > This is a big part of the strength of inline assembler. It does mean > that if you need a different target selected for your assembler code > then you need to arrange for that in your assembler code. > > So yes, this very much is about -many, other -m options, and .machine . > I discourage the kernel (as well as any other project) from using -m > options, especially -many, but that is your own choice of course. I > get sick and tired from you calling a deliberate design decision we > arrived at after years of work and weighing alternatives a "bug" though. Alan posted a good summary here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485#c10 Thanks, Nick
