@craig.topper this pass runs on IR. In the real code that prompted me to come up with this patch the BB block was split during ISel building phase, because (IUC) it was too big. And just so happens that the split was right between sext to i64 and mul. I've tried to simulate it with the code above.
@bjope Thanks. That might be a valid option for testing (although it's not really target specific at this point). However, it might be moot if it turns out there is no way to either 1) check whether two CopyFromRegs came from the same IR value or 2) find out in other ways that one node is just replicated sign bit of the other node.

One of the motivating examples (not sure how stable this IR to use as a test) is something like this (needs -mllvm -disable-cgp to prevent sext sinking):

define i64 @foo(i32 %a, i32 %b) local_unnamed_addr {
entry:
  %conv6 = sext i32 %a to i64
  %conv17 = sext i32 %b to i64
  %add = add i64 %conv6, 42
  %cmp0 = icmp slt i64 %conv17, %add
  br i1 %cmp0, label %exit, label %exit2 ; branch to prevent bb merging

Thanks for submitting this. It's good to see different approaches.

I see. It also looks like "run_order" was switched to llvm_project_revision for some reason (I couldn't quite get why - is it simply because the old schema used it? Seems not worth it even if it's hard to correct it in LNT), but if it won't change the behavior (i.e. produced reports) for existing LNT users then it's fine. There seems to be some confusion around what run order is supposed to be already.

What does this mean for the existing v1 users? Will they continue using v1 format, i.e. will LNT keep using whatever it was using before this patch or will it switch to v2? Btw, is there some place/short summary of the rationale behind v2? Not really related to this patch per se, just want to understand the implication of the new format for the downstream users.

Any particular reason this was never followed through? This pass might solve https://bugs.llvm.org/show_bug.cgi?id=42965 .

ping

How big is the slowdown?

Would that also skip checks for something like shared_ptr?

ping

Would it make clang-format linker available to Phabricator automatically or it would still be required to be run manually by those submitting the diffs?

I'm also using pycodestyle 2.4.0. The error/warning was not about raw strings in regexps, rather illegal escape sequences, i.e.:

@kristof.beyls Thanks. Yes, I don't have commit access as I indicated in my previous reply (unless I was somehow given one without my knowledge). I'd be happy if you could commit this on my behalf.

@MatzeB ping

@MatzeB Is there something else I should do for this to be commited? First time using the Phabricator so I'm a bit unfamiliar with the process.

In D45000#1078268, @MatzeB wrote:

Tgiugh this is another sign that the global_status view probably isn‘t used byanyone ans has no tests. I still think we should just remove it...

ping

I see no changes between Diff 143597 and Diff 143602.