diff options
author | Philip Reames <listmail@philipreames.com> | 2018-11-11 21:13:09 +0000 |
---|---|---|
committer | Philip Reames <listmail@philipreames.com> | 2018-11-11 21:13:09 +0000 |
commit | 18945d6c994cb9976a3907508c2da4fad8636a4b (patch) | |
tree | 505fb10defff64e153d6127edef4296ce1805c33 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h | |
parent | d345e9cff5a4bfe259e2318765f5d9fe6b959a00 (diff) | |
download | bcm5719-llvm-18945d6c994cb9976a3907508c2da4fad8636a4b.tar.gz bcm5719-llvm-18945d6c994cb9976a3907508c2da4fad8636a4b.zip |
[GCRoot] Remove some unneccessary complexity
The GCStrategy provides three configuration options were are largely redundant.
1) Support for conditionally lowering gcread and gcwrite to loads and stores. This is redundant since any GC which wished to use these abstractions would lower them out of existance before the built in lowering anyways. As such, there's no need to have the lowering being conditional.
2) Conditional initialization for allocas marked via gcroot. Semantically, roots have to be initialized before first potential use. Arguably, the frontend really should have responsibility for that, but the old API allowed the frontend to ignore this detail. Only one builtin GC used the non-initializing mode. Since no one to my knowledge actually uses the ErlangGC strategy, I decide the slight pessimization was worth the simplicity. If that turns out to be problematic, we can always improve the insertion algorithm to detect more existing initializing stores.
llvm-svn: 346621
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h')
0 files changed, 0 insertions, 0 deletions