diff options
author | Chandler Carruth <chandlerc@gmail.com> | 2016-03-10 15:31:17 +0000 |
---|---|---|
committer | Chandler Carruth <chandlerc@gmail.com> | 2016-03-10 15:31:17 +0000 |
commit | 37f1f122269f207b7d7523cd29bc56bfe61b17e3 (patch) | |
tree | f528f283ba4c124b9d8e5d17b8c4912b729f0278 /lldb/packages/Python/lldbsuite/test/dotest.py | |
parent | 14f0077f38a9714e56824c2c9da1f37b9293d42e (diff) | |
download | bcm5719-llvm-37f1f122269f207b7d7523cd29bc56bfe61b17e3.tar.gz bcm5719-llvm-37f1f122269f207b7d7523cd29bc56bfe61b17e3.zip |
[SROA] Fix PR25873, which Andrea Di Biagio analyzed the daylights out
of, and I misdiagnosed for months and months.
Andrea has had a patch for this forever, but I just couldn't see how
it was fixing the root cause of the problem. It didn't make sense to me,
even though the patch was perfectly good and the analysis of the actual
failure event was *fantastic*.
Well, I came back to it today because the patch has sat for *far* too
long and needs attention and decided I wouldn't let it go until I really
understood what was going on. After quite some time in the debugger,
I finally realized that in fact I had just missed an important case with
my previous attempt to fix PR22093 in r225149. Not only do we need to
handle loads that won't be split, but stores-of-loads that we won't
split. We *do* actually have enough logic in the presplitting to form
new slices for split stores.... *unless* we decided not to split them!
I'm so sorry that it took me this long to come to the realization that
this is the issue. It seems so obvious in hind sight (of course).
Anyways, the fix becomes *much* smaller and more focused. The fact that
we're left doing integer smashing is related to the FIXME in my original
commit: fundamentally, we're not aggressive about pre-splitting for
loads and stores to the same alloca. If we want to get aggressive about
this, it'll need both what Andrea had put into the proposed fix, but
also a *lot* more logic to essentially iteratively pre-split the alloca
until we can't do any more. As I said in that commit log, its really
unclear that this is the right call. Instead, the integer blending and
letting targets lower this to narrower stores seems slightly better. But
we definitely shouldn't really go down that path just to fix this bug.
Again, tons of thanks are owed to Andrea and others at Sony for working
on this bug. I really should have seen what was going on here and
re-directed them sooner. =////
llvm-svn: 263121
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/dotest.py')
0 files changed, 0 insertions, 0 deletions