[StackProtector] Ignore certain intrinsics when calculating sspstrong heuristic.
authorMatt Davis <Matthew.Davis@sony.com>
Fri, 6 Apr 2018 20:14:13 +0000 (20:14 +0000)
committerMatt Davis <Matthew.Davis@sony.com>
Fri, 6 Apr 2018 20:14:13 +0000 (20:14 +0000)
commit13b8331054a4a8434e1dbdca03ee4776b738be8a
tree58b8c6bccf9870c96cc20105dfc1b69753ad3eb4
parenteea7062c3a131718efe63f83499d9d78183cc85b
[StackProtector] Ignore certain intrinsics when calculating sspstrong heuristic.

Summary:
The 'strong' StackProtector heuristic takes into consideration call instructions.
Certain intrinsics, such as lifetime.start, can cause the
StackProtector to protect functions that do not need to be protected.

Specifically, a volatile variable, (not optimized away), but belonging to a stack
allocation will encourage a llvm.lifetime.start to be inserted during
compilation. Because that intrinsic is a 'call' the strong StackProtector
will see that the alloca'd variable is being passed to a call instruction, and
insert a stack protector. In this case the intrinsic isn't really lowered to a
call. This can cause unnecessary stack checking, at the cost of additional
(wasted) CPU cycles.

In the future we should rely on TargetTransformInfo::isLoweredToCall, but as of
now that routine considers all intrinsics as not being lowerable. That needs
to be corrected, and such a change is on my list of things to get moving on.

As a side note, the updated stack-protector-dbginfo.ll test always seems to
pass.  I never see the dbg.declare/dbg.value reaching the
StackProtector::HasAddressTaken, but I don't see any code excluding dbg
intrinsic calls either, so I think it's the safest thing to do.

Reviewers: void, timshen

Reviewed By: timshen

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D45331

llvm-svn: 329450
llvm/lib/CodeGen/StackProtector.cpp
llvm/test/CodeGen/X86/stack-protector-dbginfo.ll
llvm/test/CodeGen/X86/stack-protector.ll