summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/expression_command/context-object-objc
diff options
context:
space:
mode:
authorPeter Collingbourne <peter@pcc.me.uk>2019-07-22 22:13:46 +0000
committerPeter Collingbourne <peter@pcc.me.uk>2019-07-22 22:13:46 +0000
commit710605c0853199bb447d537c3271e3e79894149e (patch)
tree33bf4e65d63a9410ab523ec6d84f7a4d71521dcf /lldb/packages/Python/lldbsuite/test/expression_command/context-object-objc
parent95cbc3da8871f43c1ce2b2926afaedcd826202b1 (diff)
downloadbcm5719-llvm-710605c0853199bb447d537c3271e3e79894149e.tar.gz
bcm5719-llvm-710605c0853199bb447d537c3271e3e79894149e.zip
Analysis: Don't look through aliases when simplifying GEPs.
It is not safe in general to replace an alias in a GEP with its aliasee if the alias can be replaced with another definition (i.e. via strong/weak resolution (linkonce_odr) or via symbol interposition (default visibility in ELF)) while the aliasee cannot. An example of how this can go wrong is in the included test case. I was concerned that this might be a load-bearing misoptimization (it's possible for us to use aliases to share vtables between base and derived classes, and on Windows, vtable symbols will always be aliases in RTTI mode, so this change could theoretically inhibit trivial devirtualization in some cases), so I built Chromium for Linux and Windows with and without this change. The file sizes of the resulting binaries were identical, so it doesn't look like this is going to be a problem. Differential Revision: https://reviews.llvm.org/D65118 llvm-svn: 366754
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/context-object-objc')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud