https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |15.2

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think we want to do something about this even for 15.2, people are hitting
this in the wild, see e.g.
https://github.com/protocolbuffers/protobuf/issues/21333#issuecomment-3051822792
(the user didn't bother to provide details, so the above is just me trying to
reproduce what I think is a problem).

Dunno what exactly and where though.
For 15.2, perhaps it would be enough to punt on IPA optimizations which remove
arguments or change their types if the function fun->has_musttail.  That
shouldn't affect code which doesn't use musttail attribute.
Any ideas where that could be done?

Dunno if we can do better for trunk, computing everything that calls.cc
computes to figure out
  /* If this function requires more stack slots than the current
     function, we cannot change it into a sibling call.
     crtl->args.pretend_args_size is not part of the
     stack allocated by our caller.  */
might be hard at IPA time.

And yet another case I'm worried about are if we decide to use different
calling convention for the fun->has_musttail functions (but not the ones which
are musttail called).  E.g. if caller and callee have 3 int arguments on ia32,
and we decide to use regparm 1, 2 or 3 for the caller of the musttail callee
but callee remains regparm 0.
Or do we optimize only leaf functions?  I think if caller is say regparm 2, it
would use just one stack slot and if callee is regparm 0, it would use 3 and so
tail call would be disallowed.

Obviously, if users use regparm or have callers with fewer arguments in the
source than musttail callees, it is their decision and it can fail.  But what
I'm talking about is cases where if we don't try to optimize stuff, it works
fine, but compiler decided something that will reject the program.  The
disadvantage of punting is that fun->has_musttail calls will be less optimized,
but perhaps users of musttail attribute made a careful decision that it is
worth it.

Reply via email to