On Wed, Aug 28, 2024 at 07:12:55PM +0200, Ard Biesheuvel wrote:
On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool
[off-list ref] wrote:
quoted
quoted
In my experience, this is likely to do the opposite: it causes the
compiler to 'forget' the semantics of memcpy() and memset(), so that
explicit trivial calls will no longer be elided and replaced with
plain loads and stores (as it can no longer guarantee the equivalence)
No, the compiler will never forget those semantics. But if you tell it
your function named memset() is not the actual standard memset -- via
-fno-builtin-memset for example -- the compiler won't optimise things
involving it quite as much. You told it so eh?
That is exactly the point I am making. So how would this help in this case?
I think we agree? :-)
quoted
quoted
This needs to be fixed for Clang as well, so throwing GCC specific
flags at it will at best be a partial solution.
clang says it is a 100% plug-in replacement for GCC, so they will have
to accept all GCC flags. And in many cases they do. Cases where they
don't are bugs.
Even if this were true, we support Clang versions today that do not
support -fno-tree-loop-distribute-patterns so my point stands.
It is true. Yes, this cause problems for their users.
quoted
quoted
It is not a complete solution, unfortunately, and I guess there may be
other situations (compiler/arch combinations) where this might pop up
again.
Why do mem* not work in VDSOs? Fix that, and all these problems
disappear, and you do not need workrarounds :-)
Good point. We should just import memcpy and memset in the VDSO ELF metadata.
Yeah. In many cases GCC will replace such calls by (faster and/or
smaller) inline code anyway, but when it does leave a call, there needs
to be an external function implementing it :-)
Not sure about static binaries, though: do those even use the VDSO?
With "static binary" people usually mean "a binary not using any DSOs",
I think the VDSO is a DSO, also in this respect? As always, -static
builds are *way* less problematic (and faster and smaller :-) )
Segher