https://llvm.org/bugs/show_bug.cgi?id=30188
Michael Kuperstein <mku...@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #13 from Michael Kuperstein <mku...@google.com> ---
Thanks for the quick fix, James!
I apologize if my own remarks came off as targeting you personally - I
certainly didn't mean that. I also didn't mean that I expect an insta-revert in
such cases. All I meant was that we can't brush off performance regressions
because a commit exposed existing behavior, as opposed to actively causing the
regressions.
Back to the technical issue at hand - at least for BinarySearch you meant
r280219, not r280217, right? In any case, it seems like you've had to revert
that. Reopening the bug for now.
As a side note - (b) was exactly what I meant by bailing out of
canSinkLastInstruction early. But if this ends up becoming the permanent
solution (as opposed to fixing it properly in SROA), I'm not sure it's enough
to bail only on a store to alloca - we'll have the same problem with a GEP
relative to an alloca, etc. So this should probably use getUnderlyingObject, or
something similar.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
