it seems fixed with https://reviews.llvm.org/D114650

ping @nikic ?

In D128606#3615200, @paulwalker-arm wrote:

Is this optimisation valid? The merging SVE intrinsics have strict rules about what happens to inactive lanes. For the llvm.aarch64.sve.and the inactive lanes are set to the matching lanes of the first operand. This means that the inactive lanes of the second operand play no role in the operation and thus the example in and_i64_zero_comm is not a zeroing and.

However, given the inactive lanes of the second operand play no role, this effectively means the select is redundant and can be optimised away as an instcombine before it gets to code generation. So I guess the question is whether you are seeing this issue in real code and thus it's worth implementing the instcombine.

ping @spatel @nikic ?

In D128283#3599230, @paulwalker-arm wrote:

Hi @Allen, typically the SVE intrinsics only support legal types. This is a conscience choice because otherwise it will be very difficult to offer universal type support for all these target specific operations (i.e. where would we draw the line). Is there a reason not to use llvm.vector.reduce.and instead?

rebase to top

ping ?

redo base in SCEV according comment

In D127854#3592069, @spatel wrote:

In D127854#3591928, @Allen wrote:

rebase

I don't think this was updated correctly. There should be test diffs from the file fpcast.ll?

rebase

Add more cases according https://reviews.llvm.org/D125774#inline-1222628

In D125774#3584831, @nikic wrote:

I'm not strongly opposed to adding some basic IV reasoning to computeKnownBits(), but the implementation needs to be much more careful. I think there are at least three bugs here (missing check for predicate, no check whether this is a loop exit or continue condition, no reasoning about how the start value range relates to the end value). This requires much more extensive testing (and those tests should be simpler, not involving float operations).

Add checking the step is loop-invariant, and its loop's trip count is actually related to the PHI

@dmgreen

I'am sorry to missing apply your comment, https://reviews.llvm.org/D126700#inline-1223430

In D127596#3577439, @paulwalker-arm wrote:

I don't believe we want this functionality. We originally added it but then it got removed by D88994 as unsound because there's no instruction available to load/store predicates that are smaller than <vscale x 16 x i1>. At the C/C++ level we don't expose these "smaller" predicate types and so there shouldn't really be a route needed to load/store them. @Allen Do you have a real world use case where loading/storing them is required?

Add the check Level > AfterLegalizeVectorOps

commit f85c5079b8d has fix this

update review comment

In D125774#3520161, @efriedma wrote:

Specifically detecting this exact case doesn't really seem very useful... we should be leveraging some sort of range analysis (known bits, CorrelatedValuePropagation, etc.)

Also add subtarget feature ascend-store-address to control the aggressive order.

In D126700#3564241, @dmgreen wrote:

OK I see, thanks. In this version on godbolt I only see ordered STPQ's, perhaps you have some downstream differences that would alter the codegen?
So - do you have any other benchmark results, on any other cpus? Or as an alternative, do you think that adding a subtarget feature is an OK solution?

In D126700#3559712, @dmgreen wrote:

Do you have more details on where and when you expect this to be beneficial? It may not look like it from the review, but we did a fair amount of testing and benchmarking was done on D125377 on all kinds of CPUs (in-order vs out-of-order, little vs big, etc) to make sure that it was an improvement or benign on the cases we tried. I don't think I would be against this - so long as we had a decent reason to do so. It does constrain the scheduling graph though, so we shouldn't do so unnecessarily.

ping ?

Thanks @avieira for your detailed explanation, and according your idea, I extend more stores in D126700, can you help me review, thanks.

Address comment and add a new test case scalar_mul_bit_x0_y0_uses

Add new condtion to check that both vscales have the same types

hi @spatel , I'm sorry to trouble you again.

Now I already address all your comment before, should we wait another reviewer to also agree with this direction?

In D126532#3544144, @reames wrote:

I don't claim to fully understand this, so my comment here might be off base.

I suspect your fold can be generalized as: fold a+truncate(vscale(c1))+truncate(vscale(c2)) to a+truncate(vscale(c1)+vscale(c2))

The vscale(c1)+vscale(c2) to vscale(C1 + C2) is handled separately above already.

If this is true, that your transform reduces to proving that it's legal to common the truncate. However, as a far as I known trunc(x) + trunc(y) is always equal to trunc(x+y). So why do we need this transform at all? Shouldn't this be covered by generic trunc folds and the existing rule?

Anyways, I'm clearly missing something here. Any idea what?

hi @nikic, would you please help me check this change ? thanks!

address a missing comment

leave the capture empty according comment

rebase to the top after precommit the test cases