https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
Peter Cordes <peter at cordes dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter at cordes dot ca
--- Comment #4 from Peter Cordes <peter at cordes dot ca> ---
EAD neglected to link previous discussion about this in the initial bug report.
https://stackoverflow.com/a/57377890/224132 points out that the SysV ABI
wording is
> If the type has class MEMORY, then **the caller provides space** for the
> return value and passes the address of this storage in %rdi
We can argue semantics, but in my answer on the same question, I argued that
the implication is that that space won't alias any other space. (Because the
return-value object exists in the C abstract machine, so the default assumption
should be that it exists for real in the calling convention.)
----
Whether it's practical to look for this optimization or not, I'm still curious
about the point that @M.M made about the semantics of restrict
https://stackoverflow.com/questions/57377314/what-prevents-the-usage-of-a-function-argument-as-hidden-pointer/57436765#comment101288442_57403379
Does the callee do_something() reading a global count as happening inside the
block scope of use(Vec3 *restrict out) { ... }? The ISO C standard wording
talks about reaching the end of a block, which hasn't happened even though
`out` is not in scope inside the other function.
If so, then calling use(&global) creates UB when *out = do_something();
executes because it writes the pointed-to memory via a restrict-pointer in the
same block where it reads it from a pointer that's not derived from out.
If so, restrict would make this optimization safe if we can prove that
do_something is "noexcept" and doesn't longjmp.
