diff options
author | Matt Davis <Matthew.Davis@sony.com> | 2018-04-06 20:14:13 +0000 |
---|---|---|
committer | Matt Davis <Matthew.Davis@sony.com> | 2018-04-06 20:14:13 +0000 |
commit | 13b8331054a4a8434e1dbdca03ee4776b738be8a (patch) | |
tree | 58b8c6bccf9870c96cc20105dfc1b69753ad3eb4 /llvm/lib/TableGen | |
parent | eea7062c3a131718efe63f83499d9d78183cc85b (diff) | |
download | bcm5719-llvm-13b8331054a4a8434e1dbdca03ee4776b738be8a.tar.gz bcm5719-llvm-13b8331054a4a8434e1dbdca03ee4776b738be8a.zip |
[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
Diffstat (limited to 'llvm/lib/TableGen')
0 files changed, 0 insertions, 0 deletions