@TOCK
I've meant the surrounding context for the diff (https://llvm.org/docs/Phabricator.html#phabricator-request-review-web),
i.e. git show HEAD -U999999

The diffs lack context.

I've taken a liberty of adding more reviewers to hopefully help get this going.

Ping?

Rebased.
Had some time to come back to this.
I've tried implementing the following proposed way to get VTC locally:

Committed in 4c57b004f148dffc6db199890d91fc3e6e578972

Btw, it looks like lnt's .arcconfig is missing a callsign which broke moz-phab when I tried to submit using it.

In D62574#2135662, @ebevhan wrote:

It's generally not safe to alter address spaces below the top level. C is just very permissive about it.

What are the remaining roadblocks left before this patch can be merged? I'm interested in having a target-specific way to define the allowed explicit/implicit address space conversions.
Also, it appears that currently whether implicit casts between pointers of different AS are allowed is determined by the superset relations only, however https://reviews.llvm.org/D73360 introduced another (openCL-specific) variable into the mix: whether the conversion is a top level or not. IMHO, this should also be configured by the target, although I'm not sure whether it needs a separate hook (isBitcastNoop or similar?) or it needs to check the legality of the implicit casts differently.

ping

@RKSimon sadly not.

@dblaikie It was actually failing on some of the lit tests when compiler was compiled with EXPENSIVE_CHECKS enabled (kind of how I discovered it), but after this recent refactor which removed a sort step: https://github.com/llvm/llvm-project/commit/ed766f1bb1040a520fb5646ab75851e2b0fd66df#diff-7b43e801c5abbb03d571f9aad6af63a5L792
I don't know if the codepath with ::sort (which has those checks) can be hit from llvm IR. Instead, I've added an explicit check to AttributesTest.cpp that currently asserts.

Sorry for commenting on an old merge PR, but was looking through some asserts and stumbled on this code which raised some questions.

Updated revision with additional checks and rebased.

@lebedev.ri I've been successfully using a pass based on https://reviews.llvm.org/D12494 in a downstream port (although I'm not sure if it's enough to fix all ARM's regressions). I was planning to submit it for the review after some touch ups (i.e. it only uses legacy pm) but haven't found the time for that yet. I also need to evaluate whether it is still needed after D75908 (that might take some time).

ping

Test generated from the following C code:

@Carrot this seems to be reverted, but aggressive loop rotate still has mostly negative affect on performance in internal benchmarks that I've run.
Could you please elaborate on how branches taken was reduced from 2 to 1 (and how it was calculated) for the test case you mentioned in the https://reviews.llvm.org/D43256#1534855

@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?