This is an archive of the discontinued LLVM Phabricator instance.

StackProtector: enable tail call optimization even without musttail
ClosedPublic

Authored by taolq on Sep 14 2022, 7:18 AM.

Details

Summary

When -O2 and -fstack-protector-all are added together in clang, the tail call optimization will be disabled.
See here https://godbolt.org/z/bffPPv3zh
Because opt only emit ssqreq and tail call attribute for them,
and theses optimizations are handled by llc exactly.

So in this patch, I would like to release the condition in StackProtector.
Even for tail call (not musttail call), both stack protection and TCO(tail call optimization) will be enabled.
And finally, clang will also benefit from this small change.

Diff Detail

Event Timeline

taolq created this revision.Sep 14 2022, 7:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 14 2022, 7:18 AM
taolq requested review of this revision.Sep 14 2022, 7:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 14 2022, 7:18 AM
taolq retitled this revision from ensure protection does not disable tail call opt to StackProtector: enable tail call optimization even without musttail.Sep 14 2022, 7:37 AM
taolq edited the summary of this revision. (Show Details)

What do you think of keeping the musttail variant of the test while augmenting it with the tailcall cases?

taolq updated this revision to Diff 460403.Sep 15 2022, 7:34 AM
  • append tail cases to musttail test
taolq added a comment.EditedSep 15 2022, 7:35 AM

What do you think of keeping the musttail variant of the test while augmenting it with the tailcall cases?

Thanks for the comment.
The tests have been updated.

compnerd accepted this revision.Sep 15 2022, 10:33 AM
compnerd added inline comments.
llvm/lib/CodeGen/StackProtector.cpp
478

Please update the comment to replace the references to musttail.

llvm/test/CodeGen/AArch64/stack-protector-musttail.ll
106

Add missing newline please.

llvm/test/CodeGen/ARM/Windows/stack-protector-musttail.ll
88

Add missing newline please

This revision is now accepted and ready to land.Sep 15 2022, 10:33 AM
taolq updated this revision to Diff 460739.Sep 16 2022, 6:58 AM
  • update the comment
  • add missing newline
taolq updated this revision to Diff 460740.Sep 16 2022, 7:02 AM
  • fix format
taolq marked 3 inline comments as done.Sep 16 2022, 7:06 AM
This revision was landed with ongoing or failed builds.Sep 16 2022, 7:25 AM
This revision was automatically updated to reflect the committed changes.
efriedma added inline comments.
llvm/lib/CodeGen/StackProtector.cpp
485

Are you sure this actually does the right thing? Consider something like:

tail call void f()
call void g()
ret void

If I'm following correctly, we'll insert the guard before the call to f(), which seems wrong.

(The old code worked because a musttail call is always in tail position; a "tail" call is not.)

Do we care that the backend might not choose to tail-call a function even if it's in tail position? The "tail" marker is a hint; depending on attributes, calling convention, etc., the backend might not actually generate a tail call.

taolq added a comment.Sep 18 2022, 4:42 PM

Do we care that the backend might not choose to tail-call a function even if it's in tail position? The "tail" marker is a hint; depending on attributes, calling convention, etc., the backend might not actually generate a tail call.

I am not sure about this. Is that possible that a musttail-call is handled but a tail-call is not generated with all the same conditions?

llvm/lib/CodeGen/StackProtector.cpp
485

Thanks for your comment. I didn't notice that.
So we should remove the latter if condition.
Or let the verifier guarantee a tail call is always in the tail position.
Which one could be better?

Do we care that the backend might not choose to tail-call a function even if it's in tail position? The "tail" marker is a hint; depending on attributes, calling convention, etc., the backend might not actually generate a tail call.

I am not sure about this. Is that possible that a musttail-call is handled but a tail-call is not generated with all the same conditions?

Yes. The most obvious case is if the caller has the "disable-tail-calls" attribute, but there are others.

llvm/lib/CodeGen/StackProtector.cpp
485

Other parts of CodeGen uses llvm::isInTailCallPosition to verify tail calls; I think it accepts more constructs than the verifier.

We intentionally allow calls marked "tail" in non-tail position: it simplifies the code that does the marking, and the "tail" marking can also be used for alias analysis.

Did the review comments here ever get addressed?

taolq added a comment.May 20 2023, 4:52 AM

Did the review comments here ever get addressed?

Sorry for forgetting to solve that. I notice that I still have something to figure out. I will try my best to address it.

taolq added a comment.Oct 27 2023, 6:36 PM

Did the review comments here ever get addressed?

This issue is fixed by https://github.com/llvm/llvm-project/pull/68997