https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com,
| |jakub at gcc dot gnu.org,
| |liuhongt at gcc dot gnu.org
--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H. Peter Anvin from comment #0)
> The most logical way to address this would seem to be to allow "red-zone" to
> be specified in the assembly clobber list, just like "memory" or "cc". The
> simplest "heavy hammer" implementation would be to disable red zone support
> for the surrounding function.
The clobber can be in the form of "red-zone=N", where N is the number of
clobbered redzone bytes. This number can be handled in target hook and recorded
in cfun structure (*). The number of clobbered redzone bytes (from cfun struct)
can be accounted for when creating frame (in ix86_expand_epilogue) to offset
the start of the "real" redzone by the number of clobbered bytes. This would
effectively create a "redzone" for clobbered bytes at the start of the redzone
area.
By recording the maximum of clobbered bytes via target hook to create nested
"redzone" at the start of the redzone area, we can also solve:
TODO: If we can reserve the first 2 WORDs, for PUSH and, another
for CALL, in red-zone, we can allow local indirect jumps with
indirect thunk. */
and
/* We can't have red-zone since "call" in the indirect thunk
pushes the return address onto stack, destroying red-zone. */
comments in i386.cc, in addition to correct the handling of
IX86_BUILTIN_READ_FLAGS and IX86_FLAGS X86_BUILTIN_WRITE_FLAGS in
i386-expand.cc, which currently silently clobber redzone via push/pop combo.
We already have a temporary RED_ZONE_RESERVE at the *end* of the redzone to
handle short-lived temporaries that require stack area. So, this area has to be
moved to the beginning of the redzone and its size made dynamic.
Adding some CCs.
