One internal fuzzer test failed, investigating.
Looks a lot better than before. One possible alternative to making the subtarget then subtracting ARM, could we use the same way that nacl adds the nacl-trap feature in ParseARMTriple?
Lgtm with some more comments
Code looks fine with minor nits inlined. Please add more tests, I want to be adamant that it also works for other latch predicates.
Is this a candidate for 6.0.1?
Yes! What timing. This was indeed fixed in r327859.
(but otherwise, if we discover the paper is wrong/etc, this change looks reasnable)
Added a llvm-cxxfilt test for the demanger changes.
Done, they're no longer installed on Darwin.
While it's preferred to use ORE as an analysis pass, sometimes that's hard (e.g because it's a function pass, or simply because it's hard to thread the ORE instance through the many layers). In these cases it's fine to construct one inline. When remarks are requested this will amount to repopulating BFI for the function as the ORE instance is created.
In particular, they should have the same time bounds as us, if both algorithms operate on blocks that each contains 1 instruction.
If the exponential factor comes from repeated walking, they should be just as exponential
Thus, my assumption is we screwed up.
Address review comments.
So, staring at https://pp.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf, i don't see how we can get exponential time, and thus wonder if i screwed this up somehow.
I can see we walk blocks to find the defs and they don't have to (because of how they use it), but that should only add a factor of O(N).
When targetting Darwin we should really not be even compiling libc++/libc++abi and certainly should not have anything else compiling against their headers since at runtime the system libraries will be used and so things better compile against the system headers that match.
Do these settings accomplish that?
fixed a bug in internal testing with Loop predication pass initialization - we need to register
the BPI pass dependency.