On 11/21/22 06:49, Alexander Monakov wrote:
On Sun, 20 Nov 2022, Jeff Law wrote:
The concern, as far as I understand would be the case where the
assembly-sequence leaves an incompatible extension in the register.
Right. The question in my mind is whether or not the responsibility should be
on the compiler or on the developer to ensure the ASM output is properly
extended. If someone's writing ASMs, then to a large degree, I consider it
their responsibility to make sure things are properly extended
Right. They should also find out the hard way, with zero documentation telling
them they had to (let alone *why* they had to), and without a hypothetical
-fsanitize=abi that would catch exactly the point of the missing extension
instead of letting the program crash mysteriously at a much later point.
Uphill both ways, in a world where LLVM does not place such burden on the
programmer, and even among GCC targets only mips64 made a precedent (also
without documenting the new requirement).
They're writing assembly code -- in my book that means they'd better
have a pretty good understanding of the architecture, its limitations
and quirks.
I'm happy to give them some diagnostics, guardrails, etc etc, but
slowing down standard C code to placate someone who doesn't really know
the architecture, but is trying to write assembly code is a step too far
for me.
-- even more so
if having the compiler do it results in slower code independent of ASMs.
I think LLVM demonstrates well enough that a compiler can do a better job
than GCC at eliminating redundant extensions without upgrading requirements
for inline asm (in the usual C code, not for sub-word outputs of an asm).
Perhaps. But it's also the case the LLVM and GCC have some significant
differences in implementation. Sometimes those differences in
impementations have notable impacts on how code is generated.
jeff
Alexander
