summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
diff options
context:
space:
mode:
authorNikita Popov <npopov@redhat.com>2025-08-01 09:43:15 +0200
committerGitHub <noreply@github.com>2025-08-01 09:43:15 +0200
commit0a41e7c87ef910d0124c50354422f3b5290518e9 (patch)
tree5000b9b592a8a988ec3d495bbd3b5d42c3c0eb77 /lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
parent6d4a0935c850ec3ddfc70c4ba97b98adc35c676e (diff)
[LICM] Do not reassociate constant offset GEP (#151492)
LICM tries to reassociate GEPs in order to hoist an invariant GEP. Currently, it also does this in the case where the GEP has a constant offset. This is usually undesirable. From a back-end perspective, constant GEPs are usually free because they can be folded into addressing modes, so this just increases register pressume. From a middle-end perspective, keeping constant offsets last in the chain makes it easier to analyze the relationship between multiple GEPs on the same base, especially after CSE. The worst that can happen here is if we start with something like ``` loop { p + 4*x p + 4*x + 1 p + 4*x + 2 p + 4*x + 3 } ``` And LICM converts it into: ``` p.1 = p + 1 p.2 = p + 2 p.3 = p + 3 loop { p + 4*x p.1 + 4*x p.2 + 4*x p.3 + 4*x } ``` Which is much worse than leaving it for CSE to convert to: ``` loop { p2 = p + 4*x p2 + 1 p2 + 2 p2 + 3 } ```
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp')
0 files changed, 0 insertions, 0 deletions