diff options
| author | Philip Reames <listmail@philipreames.com> | 2019-07-22 23:33:18 +0000 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2019-07-22 23:33:18 +0000 |
| commit | 2f5543aa725c1b5af17a65b229e2573260d7cbb6 (patch) | |
| tree | f46cf6efc0632979845f49290ed0344724b0949c /lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py | |
| parent | ddccb494eeb4921d1ec3c67383250daeda77bedf (diff) | |
| download | bcm5719-llvm-2f5543aa725c1b5af17a65b229e2573260d7cbb6.tar.gz bcm5719-llvm-2f5543aa725c1b5af17a65b229e2573260d7cbb6.zip | |
[Statepoints] Fix a bug in statepoint lowering for functions w/no-realign-stack
We were silently using the ABI alignment for all of the stores generated for deopt and gc values. We'd gotten the alignment of the stack slot itself properly reduced (via MachineFrameInfo's clamping), but having the MMO on the store incorrect was enough for us to generate an aligned store to a unaligned location.
The simplest fix would have been to just pass the alignment to the helper function, but once we do that, the helper function doesn't really help. So, inline it and directly call the MMO version of DAG.getStore with a properly constructed MMO.
Note that there's a separate performance possibility here. Even if we *can* realign stacks, we probably don't *want to* if all of the stores are in slowpaths. But that's a later patch, if at all. :)
llvm-svn: 366765
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py')
0 files changed, 0 insertions, 0 deletions
