update some comments and make the changes in first-order-recurrence.ll clean

Fix the indentation

In D121585#3380414, @nikic wrote:

In D121585#3380314, @reames wrote:

Generally, I'm fine with the direction here. My sole concern is potential compile time of scanning the entire user list. (i.e. say we have 100 thousand uses in one block, and the very last one is in another block) I could see us capping the number of scanned users (we do that a bunch of places) or would want to see some time time numbers showing we don't need to.

Agreed, this needs a cutoff.

In D119839#3328631, @lebedev.ri wrote:

Abandon this?

In D119854#3325867, @lebedev.ri wrote:

In D119854#3325866, @wwei wrote:

@lebedev.ri Thanks for the patch. Does convertSwitchRangeToICmp need to be set true for O1 pipeline? Why not keep the same with other SimplifyCFGOptions for O1?

I'm not sure i understand the question.

This change disables the transform unless it's explicitly reenabled,
then explicitly reenables it for all the simplifycfg pass invocations in all pipelines,
and then un-enables it for those simplifycfg invocations that happen before IPSCCP.
Function simplification pipeline is after IPSCCP, so naturally the transform is enabled there.

@lebedev.ri Thanks for the patch. Does convertSwitchRangeToICmp need to be set true for O1 pipeline? Why not keep the same with other SimplifyCFGOptions for O1?

In D119839#3322795, @lebedev.ri wrote:

It doesn't look like something SimplifyCFG should be dealing with.

rebased.

@paulwalker-arm Thanks for your comments, the code has been modified based on your review comments, and the test file has been modified too, adding some necessary comments

update the patch, lowerShuffleToZIP_UZP_TRN removed and test file refactored.

Add some float test cases

@paulwalker-arm, could you help to review this patch and D113376?

update the patch，also there's another patch D114960 to support rev insts.

update the patch, adding sve min/max size check.

In D111862#3075475, @david-arm wrote:

Hi @wwei, have you done any performance measurements with this change on hardware to see what effect it has on some benchmarks?

ping

The detailed explanation is：
Before post-ra scheduling, initial order of instructions：

A:    ... implicit-def dead $nzcv
B:    ... implicit-def $nzcv, implicit-def dead $nzcv
C:    ... implicit-def $nzcv
D:    ... implicit killed $nzcv    (use)

In the right way, the relationship should look like this after building the sched graph.

Yes, we need to call transferImpOps here, because it will copy the implict operand include the flag--like dead flag.
But BuildMI will ignore the flag, so the changes in this MR will use CreateMachineInstr(.... /*NoImplicit=*/true) to avoid adding duplicate implict operands
I will try to explain why there may have correct issues in postra scheduling later.
The test case is updated in : https://bugs.llvm.org/show_bug.cgi?id=51711

In D108635#2964494, @skatkov wrote:

It seems that correct fix should be something different.
The underlying idea of implementation is as follows:
We built phi nodes to get, for example, base address in a point of usage. (in you example it is an offset).
Now we try to find whether there are already existing phi nodes which provide us with the base.
So we try to match all new phi nodes to already existed.
The bug you found actually happened due to we tried to match new phi node to another new phi node and at the end it results in the bug.

So I guess the better fix would be to just ignore new phi nodes when we try to map new phi node to old one.

@skatkov Thank you for the explanation，I have updated the patch.

In D108103#2946161, @lebedev.ri wrote:

Found, please see https://reviews.llvm.org/D107692#2934462

ping

Update test case by using MIR

ping

update test cases mentioned in PR47462