maciej-w-rozycki wrote: > The main problem with the `noreorder` directive is bits and pieces of > manually made assembly code (inline and otherwise) sprinkled in the Linux > kernel, various libc and other libraries and programs. Their authors > typically didn’t have the R5900 erratum in mind when those pieces were > written (the R5900 might not even have existed at the time). They are > therefore potentially fatal hazards for the R5900, to be handled > accordingly. GAS is unable to warn about them, which I think is unfortunate > (hence the > [`r5900check`](https://github.com/frno7/linux/tree/ps2-v5.4/tools/r5900check) > tool was made for this purpose, as mentioned).
This is correct, but up to the respective handcoded assembly code writers to sort out. As recently as last month I discussed a NetBSD kernel issue from a missed load delay slot wreaking havoc in a `noreorder` block on MIPS I hardware. The block spanned the whole .S source file for no apparent reason and it was clear from the source that letting the assembler schedule delay slots automatically would produce optimal code across all the ISA levels while relieving the writer from the effort to chase all the instructions that need manual intervention owing to the lack of interlocking at lower ISA levels. On that occasion NedBSD maintainers chose to make the minimal fix comprising a single `NOP` added by hand as required, but I think the message was received and they may try and clean up their sources eventually. > > For inline assembly there is currently no fix or warning. I could add a new > > warning flag `-Wmips-r5900-short-loop`, only active when targeting R5900 or > > when `-mfix-r5900` is used? > > That would be very nice indeed, and helpful to avoid difficult-to-find > erratum disasters. I recall that @maciej-w-rozycki objected to it for GAS > some years ago, on the grounds that they who wield the `noreorder` directive > “know what they are doing”. But as mentioned, the poor R5900 is typically > ignored by the authors in such cases. Maciej, what’s your assessment today? > :-) I maintain my objection for a general-purpose warning, however indeed it might make sense to add a diagnostic debug flag that would identify any known pipeline hazards in `noreorder` assembly code. Someone would have to volunteer contributing such code though. > Yeah, Maciej might explain this a bit better, but I think the delay slot > isn’t used in canonical MIPS assembly. So unless you have the `noreorder` > directive, your (first) example as it stands is indeed an infinite loop > because the ADDIU is outside the loop... Later revisions of the MIPS ISA > removed the delay slot in hardware too, if memory serves me, as it can be > considered an architectural mistake. Correct, the MIPS assembly dialect is meant to hide these architectural details behind assembly-language macros. For more information on the MIPS assembly language I can recommend Dominic Sweetman's _See MIPS Run_ printed book (2nd edition is more up to date), or _IDT MIPS Microprocessor Family Software Reference Manual_ PDF document co-authored by Dominic (who I worked with at the same office ~20 years ago). Both sources feature a chapter specifically on the MIPS assembly dialect (rather than just an instruction set reference as the ISA documents and vendor documentation do). https://github.com/llvm/llvm-project/pull/176666 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
