On Wed, 2 Apr 2025, Jacek Caban wrote:
On 1.04.2025 22:43, Martin Storsjö wrote:
On Tue, 1 Apr 2025, Jacek Caban wrote:
In preparation for using naked functions.
---
For the commit message subject, perhaps you could squeeze in an
"arm64" there too, as this only covers that function? That goes for
all of these patches.
Just for the record; I'm not generally a fan of this kind of function
(global-scope "inline" asm); IMO it is messy and tricky for the
compiler (e.g. wrt LTO).
That said, I'm aware that Wine does use this construct quite a bit,
and it does work there, so practically it's probably fine.
(Although I'm not sure how much LTO is tested there. Building
mingw-w64-crt with LTO is probably not a recommended setup anyway, but
it should mostly work these days. At
https://github.com/mstorsjo/llvm-mingw/commits/lto-toolchain I've got
a few unmerged things for making use of it.)
Anyway, not an objection to the approach, I know there are good
reasons for it - I just wanted to state publicly that I generally
don't favour the approach, but see the reasons for it here.
I have little experience with LTO. Wine doesn’t build with LTO out of
the box, it requires some trickery with __attribute__((used)). By
providing enough information for the naked function signature, it should
be possible to declare those functions as extern used on GCC.
Yes, I would expect that Wine can be quite tricky to get working with LTO,
as it uses lots of trickery. (But I do remember seeing some MRs recently
that seem to work towards it?)
That said, when using naked functions, I’d expect them to be
LTO-friendly. My understanding is that they wouldn’t be any harder for
the toolchain to handle than a regular function with some inline assembly.
Yes, naked functions probably have the same pros and cons as inline
assembly in a regular function, where the compiler does see the definition
properly contrary to global scope asm().
LLVM does implement some sort of scanning through global scope asm() to
detect symbols defined there, though, so that does still mostly work. But
if you have regular inline asm in a function, and that tries to do
creative things wrt defining symbols, those symbols don't become visible
on the LTO object level - the scanning doesn't seem to apply to asm
snippets within functions; see e.g.
https://github.com/llvm/llvm-project/issues/76046 for details.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
