[PATCH] D116308: [Huawei][Allocator] Fix the spill of status register nzcv

[Allen zhong via Phabricator via llvm-commits]

Allen added a comment.

In D116308#3217554 <https://reviews.llvm.org/D116308#3217554>, @dmgreen wrote:

> Thanks for the patch. As others have said, this test looks a lot larger than needed. I would suspect that the right combination of COPY's to and from nzcv, with something between to force the register to spill should be enough. And that way the test can hopefully be made more reliable - more likely to keep testing spilling nzcv as other code in the backend changes.
>
> I don't think we really support spilling nzcv though. The usual way this is handled is to re-compute nzcv, not to spill and reload it. I would guess that something in DAG combine is re-using the output of CCMP, not creating a new one. Newer CPUs deal with moving to/from nzcv a lot better than they used to, but older cpus can be quite slow as far as I understand.
>
> If I do generate output for the test case you have here it looks like this:
>
>   ; CHECK-NEXT:   dead $xzr = SUBSXri [[LDRXui2]], 0, 0, implicit-def $nzcv                                                                        
>   ; CHECK-NEXT:   CCMPWi %56.sub_32, 0, 4, 1, implicit-def $nzcv, implicit $nzcv                                                                   
>   ; CHECK-NEXT:   STRXui $nzcv, %stack.1, 0 :: (store (s64) into %stack.1)
>   ...
>   ; CHECK-NEXT:   $nzcv = LDRXui %stack.1, 0 :: (load (s64) from %stack.1)                                                                         
>
> Those loads/stores are not valid. It shows the importance to have decent CHECK lines.

Thanks very much for your idea, I'll add above check later, but the case will still a lot too large, do you have some idea about it ?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116308/new/

https://reviews.llvm.org/D116308