[UpdateLLCTestChecks] Allow replacing register names with variables

[greened]

Summary

Add a --scrub-reg option to convert target-specific register names to regular
expressions or FileCheck variables. --scrub-reg=names will replace register
names with FileCheck variables and track register dependencies via the
variables. --scrub-reg=deps will replace register names with a regular
expression that doesn't capture into a FileCheck variable. Dependency scrubbing
makes a test more robust in the face of incidental register name changes at the
cost of losing the ability to catch changes in the register dependency graph.

This patch only implements the regular expressions to match register names for
X86 and Lanai. Other targets will not query the option, though adding support
for it is simply a matter of checking the option and passing a regular
expression that matches register names on the target.

X86 was chosen to demonstrate how to scrub in the face of a particularly complex
set of register super-/sub-register relationships along with non-uniform naming
even within a register class. It uses a fully custom match and replace
algorithm. The Lanai implementation demonstrates the other end of the spectrum,
where super-/sub-registers all have the same names anyway so effectively they do
not matter for matching purposes. The Lanai implmentation exercises generic
routine that other targets may also use to implement scrubbing.

The x86 regular expression intentionally does not substitute for [re]?sp and
[re]?ip because it's likely that tests will want to match based on addressing
mode. Lanai does not match anything other than r[0-9]+ for similar reasons.

[sebastian-ne]

The implementation looks fine to me, but I’m not sure what the goal is.

The only advantage I see is that if the register allocation changes, the test still passes without needing changes.
But, I find the checks with regexes hard to read. The length of the regex doesn’t improve the readability either.
The names for the matches are generated from the register names, so if the register allocation changed in some commit (though the test keeps passing) and someone re-generates the test later, all the match names change – possibly on a commit that is unrelated to the one that changed the register allocation.

Using <instruction name>+<counter> like the MIR-check script does could alleviate the second issue.

[greened]

In D116832#3234787, @sebastian-ne wrote:

The implementation looks fine to me, but I’m not sure what the goal is.

Same as the goal for other checks: make them more robust in the face of non-relevant changes.

The only advantage I see is that if the register allocation changes, the test still passes without needing changes.

In the context of this change, yes. I have further features to add that will allow filtering the checks so we don't *have to* check all of the output. In that case, if code outside the checks changes (and we've said we don't care about it), then register allocation will almost certainly change and at that point you want patterns, not hard-coded names.

But, I find the checks with regexes hard to read. The length of the regex doesn’t improve the readability either.

Granted that is an issue.

The names for the matches are generated from the register names, so if the register allocation changed in some commit (though the test keeps passing) and someone re-generates the test later, all the match names change – possibly on a commit that is unrelated to the one that changed the register allocation.

Using <instruction name>+<counter> like the MIR-check script does could alleviate the second issue.

That'll change too if instruction counts change. We have this problem with update_test_checks.py as well.

[RKSimon]

Have you examples of actual test checks that you've had problems with that this is a answer to?

TBH This looks like a lot of over complication for little reward - so often when checks getting hidden by things like this we discover later on that it was also hiding flaws that we should be dealing with.

[pengfei]

Agreed with Simon, this is a disaster for doing code review. I believe almost lit tests won't be affected by RA changes given they are concise. For test cases that already complicated, the regexes make the readablity even worse.
According to my experience, jumping between xmm0 and xmm1 is much more tolerable that regexes. And yes, it's easy to hide unnoticeable flaws.

[greened]

In D116832#3235656, @RKSimon wrote:

Have you examples of actual test checks that you've had problems with that this is a answer to?

I do, but my previous employer has them. As I said, this really becomes necessary when you start paring down the checks. Code may change in other places that you don't care about and then that changes register allocation.

TBH This looks like a lot of over complication for little reward - so often when checks getting hidden by things like this we discover later on that it was also hiding flaws that we should be dealing with.

Can you explain this a bit more? What sorts of issues are you worried about?

[greened]

In D116832#3236187, @pengfei wrote:

Agreed with Simon, this is a disaster for doing code review.

That seems a bit extreme.

I believe almost lit tests won't be affected by RA changes given they are concise. For test cases that already complicated, the regexes make the readablity even worse.

I disagree that lit test cases are concise. We have a huge issue with codegen churn causing pages of testcase changes in proposed merges and very little review is done on them. I'm trying to get us to a place where we have less of that. Filtering out trivial changes to tests in reviews can be a big win.

According to my experience, jumping between xmm0 and xmm1 is much more tolerable that regexes. And yes, it's easy to hide unnoticeable flaws.

How so? I'm struggling to think of a time a regexp hid a real problem. Can you explain a bit more?

[pengfei]

We have a huge issue with codegen churn causing pages of testcase changes in proposed merges and very little review is done on them.

Can you show an example?

How so? I'm struggling to think of a time a regexp hid a real problem. Can you explain a bit more?

Here is one example: https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/X86/distancemap.mir#L66
The several [[COPY6:%[0-9]+]] are totally different things. I was fooled during the review. That's why I hate it.

[greened]

In D116832#3236435, @pengfei wrote:

We have a huge issue with codegen churn causing pages of testcase changes in proposed merges and very little review is done on them.

Can you show an example?

Sure.

Not so huge but all of the ext instructions just changed register names. That's not what the patch is about so it's irrelevant to the test.
https://reviews.llvm.org/D115646

A little bigger, shows a bigger diff than is really warranted just because of register name changes.
https://reviews.llvm.org/D64174

I don't even know how to make sense of these test diffs.
https://reviews.llvm.org/D57367

That last one has more than register name changes going on, but the register name changes make it hard to pick out the changes that matter. This is also an example of codegen tests that are just too large IMO. Look at test/CodeGen/X86/avg.ll for example. What is this actually testing? The name isn't informative, there's no comment explaining what the test is and it's a big pile of asm. Is all of that asm really necessary to check? Maybe we only care about a very specific instruction sequence. I don't know. This is why I have follow-on patches to allow update_llc_test_checks.py to filter output and create a more focused asm test by only checking for specific patterns of asm.

This isn't even *that* bad of an example. I've seen much worse, with hundreds of instructions in a test and diffs over basically the whole asm with the PR affecting many such tests. I have no idea during review if the test changes are reasonable or if the submitter simply ran update_llc_test_checks.py and submitted the result.

I have had discussions with the people that originally created the update_* scripts and they were clear the intent was *not* to just blindly run it and submit the result without careful hand-editing. Unfortunately, it has not turned out that way. It makes sense to me to provide some tools to allow some semi-automatic narrowing of tests that will hopefully be used more than the amount of hand-editing that is done now (basically zero).

How so? I'm struggling to think of a time a regexp hid a real problem. Can you explain a bit more?

Here is one example: https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/X86/distancemap.mir#L66
The several [[COPY6:%[0-9]+]] are totally different things. I was fooled during the review. That's why I hate it.

Ah, yes, I can see how that would be an issue. I'm understanding your concerns better, thanks. So maybe replacing the register name with a FileCheck variable named by the original register isn't the best. I could certainly alter this to uniquify names if it would help.

[hvdijk]

In D116832#3238011, @greened wrote:

In D116832#3236435, @pengfei wrote:

We have a huge issue with codegen churn causing pages of testcase changes in proposed merges and very little review is done on them.

Can you show an example?

Sure.

All of the examples you have provided show non-register-changes in the same tests, so the tests would still need re-generating. After re-generating, would all the register name updates still not be part of the diff on exactly the same lines?

I have had discussions with the people that originally created the update_* scripts and they were clear the intent was *not* to just blindly run it and submit the result without careful hand-editing.

The tests get a header that specifically tells you exactly which script to run with which options to fully automatically update them; regardless of original intent, that is how these update_* scripts are used now, for better or worse.

I could certainly alter this to uniquify names if it would help.

If you can find a good way to do that, so that register name updates do actually get kept out of diffs, then yes I can see how this may help.

[greened]

All of the examples you have provided show non-register-changes in the same tests, so the tests would still need re-generating. After re-generating, would all the register name updates still not be part of the diff on exactly the same lines?

You're right, they would and I should fix that. Thanks for the feedback!

I have had discussions with the people that originally created the update_* scripts and they were clear the intent was *not* to just blindly run it and submit the result without careful hand-editing.

The tests get a header that specifically tells you exactly which script to run with which options to fully automatically update them; regardless of original intent, that is how these update_* scripts are used now, for better or worse.

That sidesteps the issue, which is that we have tests with no documentation of what they're testing. The fact that update_* scripts check *all* of the output exacerbates that. Sure, for better or worse but I'd like to make it better. :)

I could certainly alter this to uniquify names if it would help.

If you can find a good way to do that, so that register name updates do actually get kept out of diffs, then yes I can see how this may help.

Ok, I'll see what I can do!

[greened]

I think I can also shorten up the regexps by being smarter about what kind of register is used in the asm. I'll work on that as well. It should make things much more readable and will flag changes in the register class, which is probably desirable.

[RKSimon]

It might be better if you do this for a target other than x86 - if generating arm/aarch64 codegen tests with the update scripts are a concern for those teams, using it there makes more sense, plus they have simpler register sets.

[greened]

Made the FileCheck variable names more generic, to limit diffs between test updates. Names are now based on register class with a uniquifying count that tracks redefinitions of registers so that changes in register def-use changes can be seen.

The X86 regexps for GPRs are complicated because only parts of register names are common across all super-/sub-classes and the prefix and suffix (non-common) parts of the names varies based on the "base" GPR name.

[greened]

In D116832#3240865, @RKSimon wrote:

It might be better if you do this for a target other than x86 - if generating arm/aarch64 codegen tests with the update scripts are a concern for those teams, using it there makes more sense, plus they have simpler register sets.

Not sure where ARM/AArch64 came into this. I don't currently work on those targets. I did X86 because it was what I was working on at the time. With the recent update I added Lanai as an example of a simpler implementation. I think the X86 implementation is valuable because it demonstrates the flexibility targets can have.

[greened]

Clarified comments.

[pengfei]

Although the new regexp looks much concise, you still haven't solved the second question @hvdijk raised.
I cannot imagine there will be a simple method that can keep the register corresponding relationship between instructions while keep them unchanged with minor instruction changes.
Counting the register number won't solve the problem either. Imagine the first instruction is removed or scheduled somewhere, will be all register names changed too? Isn't it even wores? And I evaluated it on D64174 and think the problem is still there.

[greened]

Fixed non-clobber register def regexp for x86. It was using lookbehind instead of negative lookahead for vector mnemonics.

[greened]

In D116832#3245756, @pengfei wrote:

Although the new regexp looks much concise, you still haven't solved the second question @hvdijk raised.

I cannot imagine there will be a simple method that can keep the register corresponding relationship between instructions while keep them unchanged with minor instruction changes.

Define "minor." If the instructions basically keep the same number of register operands and the number of instructions remains the same, I think the FileCheck variable names should remain stable. I would classify those as "minor" changes. Changing whole swaths of asm is not "minor" in my mind.

Counting the register number won't solve the problem either. Imagine the first instruction is removed or scheduled somewhere, will be all register names changed too? Isn't it even wores? And I evaluated it on D64174 and think the problem is still there.

If a test is going to check all of the asm generated for it, then yes, if the instruction counts change, scheduling changes, etc. then the FileCheck variable names will change, because there are different uses and defs. Remember that this enhancement is in the context of other enhancements. Namely, I have a patch (which I plan to submit soon) to filter the output such that smaller bits of asm can be checked. Then the register generalizing is applied after that. It's much less likely for small bits of focused asm to change the number of instructions, for example.

You're right that for D64174 there will be some name changes, because the number of instructions changed. I agree that there isn't a good solution for that outside of triming down what the test is looking at. Do those tests really have to look at *all* of the generated insrtuctions? I suspect not. If you narrow the scope of the check, you'll naturally get fewer register dependency changes in that scope.

[lebedev.ri]

Sorry if this has been asked before, but i think the main question here is: what's the target audience here?
Is this intended to be used solely downstream, or for certain upstream backend? Is it planned to be ever enabled by default?

[pengfei]

If the instructions basically keep the same number of register operands and the number of instructions remains the same, I think the FileCheck variable names should remain stable.

No, assuming we have a test case:

define i32 @foo(i32 %0, i32 %0, i32 %0)
; CHECK:       # %bb.0:
; CHECK-NEXT:    add %R0, %R1
; CHECK-NEXT:    add %R0, %R2
; CHECK-NEXT:    other_use_def %R1
; CHECK-NEXT:    other_use_def %R2

A patch that only exchanges the order of the first add to

; CHECK-NEXT:    add %R0, %R2
; CHECK-NEXT:    add %R0, %R1

Then, the other use and def of %R1 and %R2 will remain unchanged.
But if you are numbering the register by order, all the other %R1 and %R2 will be changed while the expected change won't be shown. This is rather confusing.

[greened]

In D116832#3252510, @lebedev.ri wrote:

Sorry if this has been asked before, but i think the main question here is: what's the target audience here?

Not asked before, and these are fair questions!

The target audience is anyone maintaining a code generator. The ultimate goal (along with other patches) is to enhance the tool to create much more focused tests. Let me give an example. In my previous job I worked a lot on X86 non-temporal load/store support. We found that we'd get a lot of spurious test changes as we changed other parts of the backend. Since the tests were only concerned with ensuring we continued to emit MOVNT instructions, I added the ability for update_llc_test_checks.py to filter and scrub output to minimize test changes caused by unrelated work. Essentially, I filtered the asm to only check MOVNT and a few auxilliary instructions and scrubbed the register names so that changes in other instructions that caused different register allocations wouldn't alter the test checks. They would continue to work as written.

Is this intended to be used solely downstream, or for certain upstream backend? Is it planned to be ever enabled by default?

I don't intend for this ever to be default. It should be strictly opt-in. As I mentioned above, I originally developed this for an in-tree backend, though it happens that the current downstream backend I'm working on can also use it.

[greened]

In D116832#3253630, @pengfei wrote:

A patch that only exchanges the order of the first add to

; CHECK-NEXT:    add %R0, %R2
; CHECK-NEXT:    add %R0, %R1

Then, the other use and def of %R1 and %R2 will remain unchanged.
But if you are numbering the register by order, all the other %R1 and %R2 will be changed while the expected change won't be shown. This is rather confusing.

Fair enough. Again, I would ask, what is the goal of the test. If it's testing scheduling, then don't scrub register names. If it's not testing scheduling, then why do we care if the scheduling change isn't caught by the test checks?

A simple uniquing counter will result in more differences than ideal. I could imagine any number of schemes to increase precision but my sense is that it's not worth it. If the user is also filtering output to create smaller test checks, then the uniquing tends to work better IME.

This is one tool in the toolbox. It's not meant for every situation.

[greened]

D117694 is the revision adding the filtering capability. We could improve this register scrubbing for more filtered cases but I'd prefer to do that as a later enhancement.

[pengfei]

In D116832#3254716, @greened wrote:

In D116832#3253630, @pengfei wrote:

A patch that only exchanges the order of the first add to

; CHECK-NEXT:    add %R0, %R2
; CHECK-NEXT:    add %R0, %R1

Then, the other use and def of %R1 and %R2 will remain unchanged.
But if you are numbering the register by order, all the other %R1 and %R2 will be changed while the expected change won't be shown. This is rather confusing.

Fair enough. Again, I would ask, what is the goal of the test. If it's testing scheduling, then don't scrub register names. If it's not testing scheduling, then why do we care if the scheduling change isn't caught by the test checks?

What I mainly wanted to demonstrate is there exists such a test generated for other purpose. For a scheduling patch, the unexpected changes of other use and def of %R1 and %R2 on an unrelated test are confusing.

; CHECK-NEXT:    add %[[GPR_1:(%r[0-9]+)]], %[[GPR_2:(%r[0-9]+)]] <== These two lines won't be changed, that's fine.
; CHECK-NEXT:    add %[[GPR_1:(%r[0-9]+)]], %[[GPR_3:(%r[0-9]+)]]
; ... ...
; CHECK-NEXT:    other_use_def %[[GPR_2]] <== These lines will be changed, that's bad.
; CHECK-NEXT:    other_use_def %[[GPR_3]] <== Same here.

A simple uniquing counter will result in more differences than ideal. I could imagine any number of schemes to increase precision but my sense is that it's not worth it. If the user is also filtering output to create smaller test checks, then the uniquing tends to work better IME.

This is one tool in the toolbox. It's not meant for every situation.

So I'm not arguing don't use this tool for number sensitive patches. I'm arguing any test cases generated in this way may confuse future number sensitive patches.
I agree filtering out unrelated code is a good idea. Then why we still need this patch if we have already filtered them?

[greened]

In D116832#3257235, @pengfei wrote:

What I mainly wanted to demonstrate is there exists such a test generated for other purpose. For a scheduling patch, the unexpected changes of other use and def of %R1 and %R2 on an unrelated test are confusing.

; CHECK-NEXT:    add %[[GPR_1:(%r[0-9]+)]], %[[GPR_2:(%r[0-9]+)]] <== These two lines won't be changed, that's fine.
; CHECK-NEXT:    add %[[GPR_1:(%r[0-9]+)]], %[[GPR_3:(%r[0-9]+)]]
; ... ...
; CHECK-NEXT:    other_use_def %[[GPR_2]] <== These lines will be changed, that's bad.
; CHECK-NEXT:    other_use_def %[[GPR_3]] <== Same here.

Ok, I gotcha. I think maybe it would be useful to add (in a follow-on patch) the ability to not care about register dependencies at all, so not generate any FileCheck variables and use just pure regular expressions to scrub the register names. That would give flexibility to allow testing different scenarios.

I agree filtering out unrelated code is a good idea. Then why we still need this patch if we have already filtered them?

Because we might still want to scrub names after filtering.

[greened]

Ping.

[jdoerfert]

Not an llc person.

[greened]

Updated to change to a --scrub-reg option with a value of "names" or "deps." --scrub-reg=names will create FileCheck variables as before while --scrub-reg=deps will replace with non-capturing regular expressions.

The latter makes tests more robust in the face of irrelevant register assignment changes, at the cost of losing the ability to flag changes in the register dependence graph.

[greened]

Ping. I think the latest changes should address some of the concerns about applicability. The scrub-regs=deps option creates a very generic kind of check.

[sebastian-ne]

Looks good to me, with all the comments and fixes the generated tests look a load better than in the first version.

llvm/utils/UpdateTestChecks/asm.py

281

Typo: when -> that?

[RKSimon]

I'm still struggling to understand real use cases here - you spoke about just wanting to match specific instructions (nontemporal load/store) - but wasn't that handled by D117694 --filter and --filter-out?

I guess I'm getting worried that these scripts are experiencing feature creep for use cases that are barely a real issue.

[greened]

In D116832#3301796, @RKSimon wrote:

I'm still struggling to understand real use cases here - you spoke about just wanting to match specific instructions (nontemporal load/store) - but wasn't that handled by D117694 --filter and --filter-out?

I guess I'm getting worried that these scripts are experiencing feature creep for use cases that are barely a real issue.

The nontemporal case is just one example, but even with that use-case, consider a check like this:

; CHECK: vmovntpd %zmm0, 20(%rax, 10, 8)

If *anything* in the test (even in code that's been filtered out), causes register allocation changes then it's likely that %zmm0 and/or %rax no longer match. However, we still want to match the offset, index and scale components, so we can't just check for vmovntpd and ignore the rest of the line. That's when register scrubbing comes in handy. We don't really care what the actual registers are, just that we emittied a vmovntpd store with the correct addressing mode.

[greened]

I guess to me this just brings feature parity with update_test_checks.py to update_llc_test_checks.py. Both can now scrub variable/register names.

[pengfei]

I think my concerns still exist, even though you provide one more option. The author selects between cannot foresee what in their tests will be affected by future commit. And the --scrub-reg deps loses too much information.
Besides, comparing the introdued complexity in asm.py and the (probably) limited benefit, it's not a good deal to me.
So back to @lebedev.ri 's question, if this is mainly for downstream use, it's better to keep it downstream. Otherwise, please give a scope which in tree tests you want to apply it to, so that we can judge the value based on that.

[greened]

In D116832#3303166, @pengfei wrote:

I think my concerns still exist, even though you provide one more option. The author selects between cannot foresee what in their tests will be affected by future commit. And the --scrub-reg deps loses too much information.

There are use-cases for scrubbing names and deps. The test author should know what they are testing. If the author can't understand whether or not register names/deps are important, perhaps it's not a good test. IME this kind of scrubbing really helps for creating focused tests. This isn't an option to use blindly, the author should understand what they're doing.

Besides, comparing the introdued complexity in asm.py and the (probably) limited benefit, it's not a good deal to me.

If people want to keep generating test checks from all of the asm output, perhaps there's limited benefit. But that means we just don't care about creating focused tests. That to me is not a great outcome.

So back to @lebedev.ri 's question, if this is mainly for downstream use, it's better to keep it downstream. Otherwise, please give a scope which in tree tests you want to apply it to, so that we can judge the value based on that.

Now that D119368 is posted for review, it provides another motivating case. Most likely folks will want to scrub the temporary SDNode names from the isel output.

[lebedev.ri]

This review may be stuck/dead, consider abandoning if no longer relevant.
Removing myself as reviewer in attempt to clean dashboard.

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/lanai-reg-names.ll

+; RUN: llc -mtriple=lanai < %s | FileCheck %s
+
+define i64 @i64_test(i64 %i) nounwind readnone {
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @i32_test(i32 %i) nounwind readnone {
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i16_test(i16 %i) nounwind readnone {
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i8_test(i8 %i) nounwind readnone {
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/lanai-reg-names.ll.noscrub.expected

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=lanai < %s | FileCheck %s
+
+define i64 @i64_test(i64 %i) nounwind readnone {
+; CHECK-LABEL: i64_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    ld 4[%fp], %r3
+; CHECK-NEXT:    ld 0[%fp], %r9
+; CHECK-NEXT:    sub %fp, 0x10, %r12
+; CHECK-NEXT:    or %r12, 0x4, %r12
+; CHECK-NEXT:    ld -16[%fp], %r13
+; CHECK-NEXT:    ld 0[%r12], %r12
+; CHECK-NEXT:    add %r9, %r13, %r13
+; CHECK-NEXT:    add %r3, %r12, %r9
+; CHECK-NEXT:    sub.f %r9, %r3, %r0
+; CHECK-NEXT:    sult %r3
+; CHECK-NEXT:    add %r13, %r3, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @i32_test(i32 %i) nounwind readnone {
+; CHECK-LABEL: i32_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    ld 0[%fp], %r3
+; CHECK-NEXT:    ld -12[%fp], %r9
+; CHECK-NEXT:    add %r3, %r9, %r9
+; CHECK-NEXT:    or %r0, 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i16_test(i16 %i) nounwind readnone {
+; CHECK-LABEL: i16_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    add %fp, 0x0, %r3
+; CHECK-NEXT:    or %r3, 0x2, %r3
+; CHECK-NEXT:    uld.h 0[%r3], %r3
+; CHECK-NEXT:    uld.h -10[%fp], %r9
+; CHECK-NEXT:    add %r3, %r9, %r3
+; CHECK-NEXT:    and %r3, 0xffff, %r9
+; CHECK-NEXT:    or %r0, 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i8_test(i8 %i) nounwind readnone {
+; CHECK-LABEL: i8_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    add %fp, 0x0, %r3
+; CHECK-NEXT:    or %r3, 0x3, %r3
+; CHECK-NEXT:    uld.b 0[%r3], %r3
+; CHECK-NEXT:    uld.b -9[%fp], %r9
+; CHECK-NEXT:    add %r3, %r9, %r3
+; CHECK-NEXT:    mov 0xff, %r9
+; CHECK-NEXT:    and %r3, %r9, %r9
+; CHECK-NEXT:    or %r0, 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/lanai-reg-names.ll.scrub.expected

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --scrub-reg-names
+; RUN: llc -mtriple=lanai < %s | FileCheck %s
+
+define i64 @i64_test(i64 %i) nounwind readnone {
+; CHECK-LABEL: i64_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    ld 4[%fp], [[GPR_1:(%r[0-9]+)]]
+; CHECK-NEXT:    ld 0[%fp], [[GPR_2:(%r[0-9]+)]]
+; CHECK-NEXT:    sub %fp, 0x10, [[GPR_3:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_3]], 0x4, [[GPR_4:(%r[0-9]+)]]
+; CHECK-NEXT:    ld -16[%fp], [[GPR_5:(%r[0-9]+)]]
+; CHECK-NEXT:    ld 0[[[GPR_4]]], [[GPR_6:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_2]], [[GPR_5]], [[GPR_7:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_1]], [[GPR_6]], [[GPR_8:(%r[0-9]+)]]
+; CHECK-NEXT:    sub.f [[GPR_8]], [[GPR_1]], [[GPR_9:(%r[0-9]+)]]
+; CHECK-NEXT:    sult [[GPR_10:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_7]], [[GPR_10]], %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @i32_test(i32 %i) nounwind readnone {
+; CHECK-LABEL: i32_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    ld 0[%fp], [[GPR_1:(%r[0-9]+)]]
+; CHECK-NEXT:    ld -12[%fp], [[GPR_2:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_1]], [[GPR_2]], [[GPR_3:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_4:(%r[0-9]+)]], 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i16_test(i16 %i) nounwind readnone {
+; CHECK-LABEL: i16_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    add %fp, 0x0, [[GPR_1:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_1]], 0x2, [[GPR_2:(%r[0-9]+)]]
+; CHECK-NEXT:    uld.h 0[[[GPR_2]]], [[GPR_3:(%r[0-9]+)]]
+; CHECK-NEXT:    uld.h -10[%fp], [[GPR_4:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_3]], [[GPR_4]], [[GPR_5:(%r[0-9]+)]]
+; CHECK-NEXT:    and [[GPR_5]], 0xffff, [[GPR_6:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_7:(%r[0-9]+)]], 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @i8_test(i8 %i) nounwind readnone {
+; CHECK-LABEL: i8_test:
+; CHECK:       ! %bb.0:
+; CHECK-NEXT:    st %fp, [--%sp]
+; CHECK-NEXT:    add %sp, 0x8, %fp
+; CHECK-NEXT:    sub %sp, 0x10, %sp
+; CHECK-NEXT:    add %fp, 0x0, [[GPR_1:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_1]], 0x3, [[GPR_2:(%r[0-9]+)]]
+; CHECK-NEXT:    uld.b 0[[[GPR_2]]], [[GPR_3:(%r[0-9]+)]]
+; CHECK-NEXT:    uld.b -9[%fp], [[GPR_4:(%r[0-9]+)]]
+; CHECK-NEXT:    add [[GPR_3]], [[GPR_4]], [[GPR_5:(%r[0-9]+)]]
+; CHECK-NEXT:    mov 0xff, [[GPR_6:(%r[0-9]+)]]
+; CHECK-NEXT:    and [[GPR_5]], [[GPR_6]], [[GPR_7:(%r[0-9]+)]]
+; CHECK-NEXT:    or [[GPR_8:(%r[0-9]+)]], 0x0, %rv
+; CHECK-NEXT:    ld -4[%fp], %pc ! return
+; CHECK-NEXT:    add %fp, 0x0, %sp
+; CHECK-NEXT:    ld -8[%fp], %fp
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/x86-reg-names.ll

+; RUN: llc -mtriple=x86_64-unknown-linux -mattr=+avx512vl < %s | FileCheck %s
+
+@x512 = dso_local global <16 x i32> zeroinitializer, align 4
+@x256 = dso_local global <8 x i32> zeroinitializer, align 4
+@x128 = dso_local global <4 x i32> zeroinitializer, align 4
+
+define <16 x i32> @zmm_k_rip_reg_test(<16 x i32> %i, <16 x i32> %j, <16 x i32> %mask1) nounwind readnone {
+  %x = load <16 x i32>, <16 x i32> * @x512
+  %mask = icmp ne <16 x i32> %mask1, %x
+  %add = add <16 x i32> %i, %j
+  %r = select <16 x i1> %mask, <16 x i32> %add, <16 x i32> zeroinitializer
+  ret <16 x i32> %r
+}
+
+define <8 x i32> @ymm_k_rip_reg_test(<8 x i32> %i, <8 x i32> %j, <8 x i32> %mask1) nounwind readnone {
+  %x = load <8 x i32>, <8 x i32> * @x256
+  %mask = icmp ne <8 x i32> %mask1, %x
+  %add = add <8 x i32> %i, %j
+  %r = select <8 x i1> %mask, <8 x i32> %add, <8 x i32> zeroinitializer
+  ret <8 x i32> %r
+}
+
+define <4 x i32> @xmm_k_rip_reg_test(<4 x i32> %i, <4 x i32> %j, <4 x i32> %mask1) nounwind readnone {
+  %x = load <4 x i32>, <4 x i32> * @x128
+  %mask = icmp ne <4 x i32> %mask1, %x
+  %add = add <4 x i32> %i, %j
+  %r = select <4 x i1> %mask, <4 x i32> %add, <4 x i32> zeroinitializer
+  ret <4 x i32> %r
+}
+
+define i64 @gpr64_rsp_reg_test(i64 %i) nounwind readnone {
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @gpr32_rsp_reg_test(i32 %i) nounwind readnone {
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr16_rsp_reg_test(i16 %i) nounwind readnone {
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr8_rsp_reg_test(i8 %i) nounwind readnone {
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/x86-reg-names.ll.noscrub.expected

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=x86_64-unknown-linux -mattr=+avx512vl < %s | FileCheck %s
+
+@x512 = dso_local global <16 x i32> zeroinitializer, align 4
+@x256 = dso_local global <8 x i32> zeroinitializer, align 4
+@x128 = dso_local global <4 x i32> zeroinitializer, align 4
+
+define <16 x i32> @zmm_k_rip_reg_test(<16 x i32> %i, <16 x i32> %j, <16 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: zmm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x512(%rip), %zmm2, %k1
+; CHECK-NEXT:    vpaddd %zmm1, %zmm0, %zmm0 {%k1} {z}
+; CHECK-NEXT:    retq
+  %x = load <16 x i32>, <16 x i32> * @x512
+  %mask = icmp ne <16 x i32> %mask1, %x
+  %add = add <16 x i32> %i, %j
+  %r = select <16 x i1> %mask, <16 x i32> %add, <16 x i32> zeroinitializer
+  ret <16 x i32> %r
+}
+
+define <8 x i32> @ymm_k_rip_reg_test(<8 x i32> %i, <8 x i32> %j, <8 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: ymm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x256(%rip), %ymm2, %k1
+; CHECK-NEXT:    vpaddd %ymm1, %ymm0, %ymm0 {%k1} {z}
+; CHECK-NEXT:    retq
+  %x = load <8 x i32>, <8 x i32> * @x256
+  %mask = icmp ne <8 x i32> %mask1, %x
+  %add = add <8 x i32> %i, %j
+  %r = select <8 x i1> %mask, <8 x i32> %add, <8 x i32> zeroinitializer
+  ret <8 x i32> %r
+}
+
+define <4 x i32> @xmm_k_rip_reg_test(<4 x i32> %i, <4 x i32> %j, <4 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: xmm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x128(%rip), %xmm2, %k1
+; CHECK-NEXT:    vpaddd %xmm1, %xmm0, %xmm0 {%k1} {z}
+; CHECK-NEXT:    retq
+  %x = load <4 x i32>, <4 x i32> * @x128
+  %mask = icmp ne <4 x i32> %mask1, %x
+  %add = add <4 x i32> %i, %j
+  %r = select <4 x i1> %mask, <4 x i32> %add, <4 x i32> zeroinitializer
+  ret <4 x i32> %r
+}
+
+define i64 @gpr64_rsp_reg_test(i64 %i) nounwind readnone {
+; CHECK-LABEL: gpr64_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    movq %rdi, %rax
+; CHECK-NEXT:    addq -{{[0-9]+}}(%rsp), %rax
+; CHECK-NEXT:    retq
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @gpr32_rsp_reg_test(i32 %i) nounwind readnone {
+; CHECK-LABEL: gpr32_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    movl %edi, %eax
+; CHECK-NEXT:    addl -{{[0-9]+}}(%rsp), %eax
+; CHECK-NEXT:    retq
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr16_rsp_reg_test(i16 %i) nounwind readnone {
+; CHECK-LABEL: gpr16_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    addw -{{[0-9]+}}(%rsp), %di
+; CHECK-NEXT:    movzwl %di, %eax
+; CHECK-NEXT:    retq
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr8_rsp_reg_test(i8 %i) nounwind readnone {
+; CHECK-LABEL: gpr8_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    addb -{{[0-9]+}}(%rsp), %dil
+; CHECK-NEXT:    movzbl %dil, %eax
+; CHECK-NEXT:    retq
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/Inputs/x86-reg-names.ll.scrub.expected

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --scrub-reg-names
+; RUN: llc -mtriple=x86_64-unknown-linux -mattr=+avx512vl < %s | FileCheck %s
+
+@x512 = dso_local global <16 x i32> zeroinitializer, align 4
+@x256 = dso_local global <8 x i32> zeroinitializer, align 4
+@x128 = dso_local global <4 x i32> zeroinitializer, align 4
+
+define <16 x i32> @zmm_k_rip_reg_test(<16 x i32> %i, <16 x i32> %j, <16 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: zmm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x512(%rip), %z[[VEC_1:(mm[0-9]+)]], %[[MASK_1:(k[0-9]+)]]
+; CHECK-NEXT:    vpaddd %z[[VEC_2:(mm[0-9]+)]], %z[[VEC_3:(mm[0-9]+)]], %z[[VEC_4:(mm[0-9]+)]] {%[[MASK_1]]} {z}
+; CHECK-NEXT:    retq
+  %x = load <16 x i32>, <16 x i32> * @x512
+  %mask = icmp ne <16 x i32> %mask1, %x
+  %add = add <16 x i32> %i, %j
+  %r = select <16 x i1> %mask, <16 x i32> %add, <16 x i32> zeroinitializer
+  ret <16 x i32> %r
+}
+
+define <8 x i32> @ymm_k_rip_reg_test(<8 x i32> %i, <8 x i32> %j, <8 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: ymm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x256(%rip), %y[[VEC_1:(mm[0-9]+)]], %[[MASK_1:(k[0-9]+)]]
+; CHECK-NEXT:    vpaddd %y[[VEC_2:(mm[0-9]+)]], %y[[VEC_3:(mm[0-9]+)]], %y[[VEC_4:(mm[0-9]+)]] {%[[MASK_1]]} {z}
+; CHECK-NEXT:    retq
+  %x = load <8 x i32>, <8 x i32> * @x256
+  %mask = icmp ne <8 x i32> %mask1, %x
+  %add = add <8 x i32> %i, %j
+  %r = select <8 x i1> %mask, <8 x i32> %add, <8 x i32> zeroinitializer
+  ret <8 x i32> %r
+}
+
+define <4 x i32> @xmm_k_rip_reg_test(<4 x i32> %i, <4 x i32> %j, <4 x i32> %mask1) nounwind readnone {
+; CHECK-LABEL: xmm_k_rip_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vpcmpneqd x128(%rip), %x[[VEC_1:(mm[0-9]+)]], %[[MASK_1:(k[0-9]+)]]
+; CHECK-NEXT:    vpaddd %x[[VEC_2:(mm[0-9]+)]], %x[[VEC_3:(mm[0-9]+)]], %x[[VEC_4:(mm[0-9]+)]] {%[[MASK_1]]} {z}
+; CHECK-NEXT:    retq
+  %x = load <4 x i32>, <4 x i32> * @x128
+  %mask = icmp ne <4 x i32> %mask1, %x
+  %add = add <4 x i32> %i, %j
+  %r = select <4 x i1> %mask, <4 x i32> %add, <4 x i32> zeroinitializer
+  ret <4 x i32> %r
+}
+
+define i64 @gpr64_rsp_reg_test(i64 %i) nounwind readnone {
+; CHECK-LABEL: gpr64_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    movq %{{r?}}[[GPR_1:([abcd]|[sd]i|r[0-9]+|bp)]]{{x?}}, %{{r?}}[[GPR_2:([abcd]|[sd]i|r[0-9]+|bp)]]{{x?}}
+; CHECK-NEXT:    addq -{{[0-9]+}}(%rsp), %{{r?}}[[GPR_2]]{{x?}}
+; CHECK-NEXT:    retq
+  %loc = alloca i64
+  %j = load i64, i64 * %loc
+  %r = add i64 %i, %j
+  ret i64 %r
+}
+
+define i64 @gpr32_rsp_reg_test(i32 %i) nounwind readnone {
+; CHECK-LABEL: gpr32_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    movl %{{e?}}[[GPR_1:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xd]?}}, %{{e?}}[[GPR_2:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xd]?}}
+; CHECK-NEXT:    addl -{{[0-9]+}}(%rsp), %{{e?}}[[GPR_2]]{{[xd]?}}
+; CHECK-NEXT:    retq
+  %loc = alloca i32
+  %j = load i32, i32 * %loc
+  %r = add i32 %i, %j
+  %ext = zext i32 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr16_rsp_reg_test(i16 %i) nounwind readnone {
+; CHECK-LABEL: gpr16_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    addw -{{[0-9]+}}(%rsp), %[[GPR_1:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xw]?}}
+; CHECK-NEXT:    movzwl %[[GPR_1]]{{[xw]?}}, %{{e?}}[[GPR_2:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xd]?}}
+; CHECK-NEXT:    retq
+  %loc = alloca i16
+  %j = load i16, i16 * %loc
+  %r = add i16 %i, %j
+  %ext = zext i16 %r to i64
+  ret i64 %ext
+}
+
+define i64 @gpr8_rsp_reg_test(i8 %i) nounwind readnone {
+; CHECK-LABEL: gpr8_rsp_reg_test:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    addb -{{[0-9]+}}(%rsp), %[[GPR_1:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xw]?}}l
+; CHECK-NEXT:    movzbl %[[GPR_1]]{{[xw]?}}l, %{{e?}}[[GPR_2:([abcd]|[sd]i|r[0-9]+|bp)]]{{[xd]?}}
+; CHECK-NEXT:    retq
+  %loc = alloca i8
+  %j = load i8, i8 * %loc
+  %r = add i8 %i, %j
+  %ext = zext i8 %r to i64
+  ret i64 %ext
+}

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/lanai-reg-names.test

+# REQUIRES: lanai-registered-target
+
+## Check that register names are replaced with FileCheck variables.
+# RUN: cp -f %S/Inputs/lanai-reg-names.ll %t.ll && %update_llc_test_checks --scrub-reg-names %t.ll
+# RUN: diff -u %S/Inputs/lanai-reg-names.ll.scrub.expected %t.ll
+
+## Check that running the script again does not change the result:
+# RUN: %update_llc_test_checks --scrub-reg-names %t.ll
+# RUN: diff -u %S/Inputs/lanai-reg-names.ll.scrub.expected %t.ll
+
+## Check that register names are not replaced with FileCheck variables.
+# RUN: cp -f %S/Inputs/lanai-reg-names.ll %t.ll && %update_llc_test_checks %t.ll
+# RUN: diff -u %S/Inputs/lanai-reg-names.ll.noscrub.expected %t.ll
+
+## Check that running the script again does not change the result:
+# RUN: %update_llc_test_checks %t.ll
+# RUN: diff -u %S/Inputs/lanai-reg-names.ll.noscrub.expected %t.ll

llvm/test/tools/UpdateTestChecks/update_llc_test_checks/x86-reg-names.test

+# REQUIRES: x86-registered-target
+
+## Check that register names are replaced with FileCheck variables.
+# RUN: cp -f %S/Inputs/x86-reg-names.ll %t.ll && %update_llc_test_checks --scrub-reg-names %t.ll
+# RUN: diff -u %S/Inputs/x86-reg-names.ll.scrub.expected %t.ll
+
+## Check that running the script again does not change the result:
+# RUN: %update_llc_test_checks --scrub-reg-names %t.ll
+# RUN: diff -u %S/Inputs/x86-reg-names.ll.scrub.expected %t.ll
+
+## Check that register names are not replaced with FileCheck variables.
+# RUN: cp -f %S/Inputs/x86-reg-names.ll %t.ll && %update_llc_test_checks %t.ll
+# RUN: diff -u %S/Inputs/x86-reg-names.ll.noscrub.expected %t.ll
+
+## Check that running the script again does not change the result:
+# RUN: %update_llc_test_checks %t.ll
+# RUN: diff -u %S/Inputs/x86-reg-names.ll.noscrub.expected %t.ll

llvm/utils/UpdateTestChecks/asm.py

SCRUB_X86_SPILL_RELOAD_RE = (
     re.compile(
         r'-?\d+\(%([er])[sb]p\)(.*(?:Spill|Reload))$',
         flags=re.M))
 SCRUB_X86_SP_RE = re.compile(r'\d+\(%(esp|rsp)\)')
 SCRUB_X86_RIP_RE = re.compile(r'[.\w]+\(%rip\)')
 SCRUB_X86_LCP_RE = re.compile(r'\.?LCPI[0-9]+_[0-9]+')
 SCRUB_X86_RET_RE = re.compile(r'ret[l|q]')
 
+# ===----------------------- Register scrubbing -----------------------------===
+
+# Design goals:
+#
+# 1. Limit the diffs of register-related things when updating tests.  We want to
+#    filter out irrelevant (to some tests) changes in register names.
+#
+# 2. Reduce the complexity of match regexps as much as possible.
+#
+# These goals drive the use of register class names for FileCheck variables.
+# Replacing a register name with a unique register-class-based FileCheck name
+# means that mere changes to register names within a class will not cause
+# differences in test CHECK lines.  However, changes from one register class to
+# another *will* cause (desirable) differences.  This also simplifies regular
+# expressions because each regexp need only match registers from a particular
+# class, not all possible machine registers.
+
+# Given a match object, a function that maps a register to a register class name
+# and a function that returns whether the match is a register definition, return
+# a replacement for the matched string.  This is a general utility most
+# architectures can use to quickly implement register scrubbing.  It assumes
+# that either the target does not have subregisters or that the tests for an
+# architecture with subregisters doesn't care about tracking sub-/super-register
+# dependencies.
+#
+# The reg_class_func and reg_def_func are called with the match object:
+#
+#     reg_def_func(match)
+#
+# The match object should have the register name in group 1.
+#
+# The target will provide the reg_class_func and reg_def_func and will call
+# scrub_reg_names with a lambda that captures that function:
+#
+#     asm = scrub_reg_names(
+#      asm,
+#      TARGET_REG_PATTERNS,
+#      lambda match: scrub_reg_get_reg_replament(
+#        match, TARGET_REG_CLASS_FUNC, TARGET_REG_DEF_FUNC
+#      )
+#    )
+#
+# The reg_class_func should return a string indicating the register class of the
+# matched register.  The string can be anything at all as long as it is
+# consistent.
+#
+# The reg_def_func should return True if the matched register is defined by the
+# instruction.
+#
+def scrub_reg_get_reg_replacement(match, reg_class_func, reg_def_func):
+  # Create a FileCheck variable name based on a register class name.
+  def get_reg_name(reg_class, count):
+    return reg_class + '_' + str(count)
+
+  # Create a FileCheck variable from regex.
+  def get_reg_definition(name, pattern):
+    return '[[' + name + ':' + pattern + ']]'
+
+  # Use a FileCheck variable.
+  def get_reg_use(name):
+    return '[[' + name + ']]'
+
+  reg = match.group(1)
+  reg_class = reg_class_func(match)
+  reg_pattern = match.re.pattern
+
+  # Register renaming.  In order to uniquify FileCheck variable names when
+  # registers are redefined, we employ a renaming scheme, not unlike those used
+  # in OOO hardware.  The first time we see a register of a particular class, it
+  # gets a name consisting of the register class name concatenated with a
+  # per-class counter.  All uses of that register value will use the generated
+  # name.  When a register of a particular class is redefined, we increment the
+  # count and generate a new name, when is then used for subsequent uses of the
+  # register.
+  #
+  # Using register class names generalizes the register names, limiting
+  # differences caused by mere register name changes.
+
+  count_index = reg_class
+
+  # Prefix with register class in case a substring appears in multiple classes.
+  rename_index = reg_class + '_' + reg
+
+  count = scrub_reg_get_reg_replacement.class_count.get(count_index, 0)
+
+  # See if this is either a completely new appearance of a register or a
+  # register (re-)definition.
+
+  if rename_index not in scrub_reg_get_reg_replacement.renamer or reg_def_func(
+      match
+  ):
+    count += 1
+    name = get_reg_name(reg_class, count)
+    rv = get_reg_definition(name, reg_pattern)
+    common.debug('   Def or new appearance of ' + reg + ', replacing with ' +
+                 rv)
+  else:
+    name = scrub_reg_get_reg_replacement.renamer[rename_index]
+    rv = get_reg_use(name)
+    common.debug('   Use of ' + reg + ', replacing with ' + rv)
+
+  scrub_reg_get_reg_replacement.renamer[rename_index] = name
+  scrub_reg_get_reg_replacement.class_count[count_index] = count
+
+  return rv
+
+scrub_reg_get_reg_replacement.class_count = dict()
+scrub_reg_get_reg_replacement.renamer = dict()
+
+# Reset the state of the matcher.  Targets using scrub_reg_get_reg_replacement
+# should pass this as the reset_func to scrub_reg_names.
+#
+def scrub_reg_reset():
+  scrub_reg_get_reg_replacement.renamer = dict()
+  scrub_reg_get_reg_replacement.class_count = dict()
+
+# ===----------------------- Lanai Register scrubbing -----------------------===
+
+LANAI_SCRUB_REG_GPR_PATTERN = f'(%r[0-9]+)'
+
+LANAI_SCRUB_REG_REGEXPS = [
+  re.compile(LANAI_SCRUB_REG_GPR_PATTERN)
+]
+
+def LANAI_SCRUB_REG_REG_CLASS_FUNC(match):
+  reg = match.group(1)
+
+  if not reg.startswith('%r'):
+    raise Exception('Unexpected register ' + reg)
+
+  return 'GPR'
+
+LANAI_SCRUB_REG_END_LINE_PATTERN = r'\s*(;.*)?$'
+LANAI_SCRUB_REG_END_LINE_REGEXP = re.compile(LANAI_SCRUB_REG_END_LINE_PATTERN)
+
+def LANAI_SCRUB_REG_REG_DEF_FUNC(match):
+  reg = match.group(1)
+  asm_line = match.string
+  start = match.start(1)
+  end = match.end(1)
+
+  common.debug(asm_line + ': Matched ' + reg + ' at ' + str((start, end)))
+
+  if asm_line[start:end] != reg:
+    raise Exception('\'' + asm_line + '\' at position ' + str((start, end)) +
+                    ' did not match expected register ' + reg)
+
+  # If the string following the match only has whitespace and/or an option mask
+  # or modifier use and/or a comment, it is a register definition.  Any other
+  # use of a register (such as in a memory operand) would have a parenthesis or
+  # bracket after it.
+
+  match = LANAI_SCRUB_REG_END_LINE_REGEXP.match(asm_line, end)
+  if match:
+    common.debug('Matched def at ' + match.group(0))
+    return True
+
+  return False
+
+LANAI_SCRUB_REG_REG_REPLACEMENT_FUNC = lambda match: scrub_reg_get_reg_replacement(
+  match, LANAI_SCRUB_REG_REG_CLASS_FUNC, LANAI_SCRUB_REG_REG_DEF_FUNC
+)
+
+# ===----------------------- X86-64 Register scrubbing ----------------------===
+
+# Design goals:
+#
+# 1. Limit the diffs of register-related things when updating tests.  We want to
+#    filter out irrelevant (to some tests) changes in register names.
+#
+# 2. Track register dependencies between super- and sub-classes.  This catches
+#    errors such as defining a super-reg and then using a sub-reg of a different
+#    register.
+#
+# 3. Reduce the complexity of match regexps as much as possible.
+#
+# These goals are somewhat in conflict.  Because X86 GPR names are not
+# particularly consistent (for example the allowed byte/word/doubleword prefixes
+# and suffixes differ among GPRs), tracking defs across super-/sub-registers
+# involves some hefty regular expressions.  Due to limitations in FileCheck's
+# regexp support (only Extended Regular Expressions), we can't use lookahead and
+# lookbehind to constrain matches.  That means some of the regular expressions
+# can match illegal names like "ebpl."  We'll assume that enough tests run
+# without register scrubbing that the asm won't have such illegal names.
+
+# Don't match [re]?ip and [re]?sp because we likely want to match how they are
+# used in addressing.  Match [re]bp because we may have eliminated the frame
+# pointer.  We also don't have patterns for e?flags because only one register
+# would match so a pattern doesn't change anything as far as test diffs are
+# concerned.
+#
+# We assume AT&T syntax.
+
+SCRUB_X86_GPR8_PATTERN = \
+  r'(?P<reg>%((?P<gpr>[abcd])(?P<gprsfx>[hl])|' \
+  r'(?P<idx>[sd])(?P<idxsfx>il)|' \
+  r'(?P<ext>r[0-9]+)(?P<extsfx>l)|' \
+  r'(?P<bp>bp)(?P<bpsfx>l)))'
+SCRUB_X86_GPR16_PATTERN = \
+  r'(?P<reg>%((?P<gpr>[abcd])(?P<gprsfx>x)|' \
+  r'(?P<idx>[sd])(?P<idxsfx>i)|' \
+  r'(?P<ext>r[0-9]+)(?P<extsfx>w)|' \
+  r'(?P<bp>bp)))'
+SCRUB_X86_GPR32_PATTERN = \
+  r'(?P<reg>%((?P<gprpfx>e)(?P<gpr>[abcd])(?P<gprsfx>x)|' \
+  r'(?P<idxpfx>e)(?P<idx>[sd])(?P<idxsfx>i)|' \
+  r'(?P<ext>r[0-9]+)(?P<extsfx>d)|' \
+  r'(?P<bppfx>e)(?P<bp>bp)))'
+SCRUB_X86_GPR64_PATTERN = \
+  r'(?P<reg>%((?P<gprpfx>r)(?P<gpr>[abcd])(?P<gprsfx>x)|' \
+  r'(?P<idxpfx>r)(?P<idx>[sd])(?P<idxsfx>i)|' \
+  r'(?P<ext>r[0-9]+)|(?P<bppfx>r)(?P<bp>bp)))'
+SCRUB_X86_ST_PATTERN = r'(?P<reg>%(?P<x87>st\([0-9]+\)))'
+SCRUB_X86_MMX_PATTERN = r'(?P<reg>%(?P<x87>mm[0-9]+))'
+SCRUB_X86_XMM_PATTERN = r'(?P<reg>%(?P<vecpfx>x)(?P<vec>mm[0-9]+))'
+SCRUB_X86_YMM_PATTERN = r'(?P<reg>%(?P<vecpfx>y)(?P<vec>mm[0-9]+))'
+SCRUB_X86_ZMM_PATTERN = r'(?P<reg>%(?P<vecpfx>z)(?P<vec>mm[0-9]+))'
+SCRUB_X86_K_PATTERN = r'(?P<reg>%(?P<mask>k[0-9]+))'
+SCRUB_X86_SEG_PATTERN = r'(?P<reg>%(?P<seg>[cdsefg]s))'
+
+# Specify a list of patterns to match.  Order is important here.  We don't want,
+# say "ax" to match when "rax" is the full register name.  These are checked in
+# order.
+
+X86_SCRUB_REG_REGEXPS = [
+  re.compile(SCRUB_X86_GPR64_PATTERN),
+  re.compile(SCRUB_X86_GPR32_PATTERN),
+  re.compile(SCRUB_X86_GPR16_PATTERN),
+  re.compile(SCRUB_X86_GPR8_PATTERN),
+  re.compile(SCRUB_X86_ZMM_PATTERN),
+  re.compile(SCRUB_X86_YMM_PATTERN),
+  re.compile(SCRUB_X86_XMM_PATTERN),
+  re.compile(SCRUB_X86_MMX_PATTERN),
+  re.compile(SCRUB_X86_ST_PATTERN),
+  re.compile(SCRUB_X86_K_PATTERN),
+  re.compile(SCRUB_X86_SEG_PATTERN)
+]
+
+# Specify a pattern to match a register definition.  This is how we know when
+# to use a new unique FileName variable.  A def is either:
+#
+# mnemonic REG(<modifiers>)?(<comment>)?<eol>
+# mnemonic (<operand>,)+ REG(<modifiers>)?(<comment>)?<eol>
+#
+# Here <modifiers> is uses of {<mask>} and {z} specifiers, which are not defs.
+#
+# Note that memory operands are not considered registers and do not define
+# registers.
+
+SCRUB_X86_COMMENT_PATTERN = r'\s*(;.*)?'
+SCRUB_X86_MASK_MODIFIER_PATTERN = r'\s*(\{\S+\}\s*)*'
+
+# Match a register definition from the end point of a register match.
+SCRUB_X86_REG_DEF_REGEXP = re.compile(
+  r'(' + SCRUB_X86_MASK_MODIFIER_PATTERN + SCRUB_X86_COMMENT_PATTERN + r')$'
+)
+
+# TODO: We might be able to merge this will the more general
+# scrub_reg_get_reg_replacement.  That would require
+# scrub_reg_get_reg_replacement to take more customization routines, for example
+# to get a register key, prefix and suffix.  This will make that routine more
+# complex for targets that don't need the flexibility.  However, most targets
+# have some kind of super-/sub-register relationship so most will need some of
+# that flexibility.
+def X86_SCRUB_REG_REPLACEMENT_FUNC(match):
+  def reg_class_func(match):
+    groups = match.groupdict()
+    reg = groups['reg']
+    if 'gpr' in groups or 'idx' in groups or 'bp' in groups or 'ext' in groups:
+      # This is a GPR-type register.
+      return 'GPR'
+    elif 'x87' in groups:
+      return 'X87FP'
+    elif 'vec' in groups:
+      return 'VEC'
+    elif 'mask' in groups:
+      return 'MASK'
+    elif 'seg' in groups:
+      return 'SEG'
+    else:
+      raise Exception('Unknown register ' + reg)
+
+  def reg_def_func(asm_line, reg, match_pos):
+    # An instruction with a register def tied to a use does *not* generate a new
+    # name.  This is because we want to ensure the used value is the same as the
+    # previous definition of the register.  Subsequent uses of the tied register
+    # must use the same name.  If a test update changes the name of the tied
+    # register, it also must have changed to the same name in the previous
+    # instruction that defined the value.  So they will still all have the same
+    # name, just as the FileCheck variables all have the same name.
+    #
+    # Here is one situation where this will not catch an incorrect register
+    # def-use chain:
+    #
+    # add %rax, %rbx
+    # sub %rcx, %rbx
+    # add %rdx, %rbx
+    #
+    # If a pass incorrectly reorders the instructions (producing a different,
+    # incorrect result), %rbx will still have the same FileCheck variable for
+    # all three instructions and we will not detect the difference in value for
+    # %rbx.  However, presumably the test will also be checking mnemonics and
+    # those will differ in their order, causing the test to fail.
+
+    start = match_pos[0]
+    end = match_pos[1]
+
+    common.debug(asm_line + ': Matched ' + reg + ' at ' + str(match_pos))
+
+    if asm_line[start:end] != reg:
+      raise Exception('\'' + asm_line + '\' at position ' + str(match_pos) +
+                      ' did not match expected register ' + reg)
+
+    # If the string following the match only has whitespace and/or an option
+    # mask or modifier use and/or a comment, it is a register definition.  Any
+    # other use of a register (such as in a memory operand) would have a
+    # parenthesis or bracket after it.
+
+    match = SCRUB_X86_REG_DEF_REGEXP.match(asm_line, end)
+    if match:
+      # This might be a tied register.  Check known mnemonics.  If it's a tied
+      # register we consider it a use so that we'll check def-use chains in
+      # these cases
+      mnemonic_match = X86_SCRUB_REG_REPLACEMENT_FUNC.mnemonic_regexp.match(
+        asm_line
+      )
+      if not mnemonic_match:
+        raise Exception('Could not find mnemonic in ' + asm_line)
+
+      mnemonic = mnemonic_match.group('mnemonic')
+
+      def_match = X86_SCRUB_REG_REPLACEMENT_FUNC.noclobber_def_op_regexp.match(
+        mnemonic
+      )
+
+      if not def_match:
+        # Tied register or use, don't consider it a def.
+        common.debug('Matched tied def or use of ' + reg + ' for ' + mnemonic)
+        return False
+
+      common.debug('Matched def at ' + match.group(0))
+      return True
+
+    common.debug('Did not match def of ' + reg + ' in ' + asm_line[end:] +
+                 ' with ' + SCRUB_X86_REG_DEF_REGEXP.pattern)
+    return False
+
+  # Create a FileCheck variable name based on a register class name.
+  def get_reg_name(reg_class, count):
+    return reg_class + '_' + str(count)
+
+  def get_replacement_rv(rv, key, prefix, suffix):
+    # Fix up the prefix and suffix so we match registers of similar class.
+    newprefix = prefix
+    newsuffix = suffix
+    if prefix == '%r' or prefix == '%e':
+      # Not a valid prefix for r[0-9]+ so make the letter optional.
+      # Unfortunately, this means we might match a 16-bit register like "ax" but
+      # since FileCheck doesn't support lookahead/lookbehind and we need to
+      # match just the register key to the FileCheck variable name, we can't
+      # easily write a prefix that is conditional on tne register key.
+      newprefix = '%{{' + prefix[1] + '?}}'
+    if suffix == 'l' or suffix == 'h' or suffix == 'b':
+      # GPR8 register.
+      newsuffix = '{{[hlb]}}'
+    elif prefix == '%' and reg_key[0] != 'k':
+      # GPR16 register, only [abcd] and r[0-9]+ have a suffix.  Make it
+      # optional.
+      newsuffix = '{{[xw]?}}'
+    elif prefix == '%e':
+      # GPR32 register, only [abcd] and r[0-9]+ have a suffix.  Make it
+      # optional.
+      newsuffix = '{{[xd]?}}'
+    elif prefix == '%r':
+      # GPR64 register, only [abcd] has a suffix.  Make it optional.
+      newsuffix = '{{x?}}'
+    return newprefix + rv + newsuffix
+
+  # Create a FileCheck variable from regex.
+  def get_reg_definition(name, reg_key, reg_prefix, reg_suffix):
+    prefix_pattern = X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns[reg_class]
+    key_pattern = X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns[reg_class]
+    suffix_pattern = X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns[reg_class]
+
+    return get_replacement_rv(
+      '[[' + name + ':' + key_pattern + ']]', reg_key, reg_prefix, reg_suffix
+    )
+
+  # Use a FileCheck variable.
+  def get_reg_use(name, reg_key, reg_prefix, reg_suffix):
+    return get_replacement_rv('[[' + name + ']]', reg_key, reg_prefix, reg_suffix)
+
+  def get_reg_subpart(reg, reg_class, regexp, part):
+    match = regexp.search(reg)
+
+    if not match:
+      raise Exception(
+        'Did not match register ' + part + ' for register ' + reg + \
+        ' in class ' + reg_class + ' using pattern ' + regexp.pattern
+    )
+
+    return match.group(1)
+
+  reg = match.group('reg')
+  common.debug('Got register ' + reg)
+  reg_class = reg_class_func(match)
+  match_pos = ( match.start(1), match.end(1) )
+
+  # The "register key" is the part of the name that matches across
+  # super-/sub-classes.  This is what we use to detect register dependencies.
+  # The prefix and suffix is the part of the register name that varies across
+  # super-/sub-class.
+
+  reg_key_regexp = X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_regexps[reg_class]
+  reg_prefix_regexp = X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_regexps[reg_class]
+  reg_suffix_regexp = X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_regexps[reg_class]
+
+  reg_key = get_reg_subpart(reg, reg_class, reg_key_regexp, 'key')
+  reg_prefix = get_reg_subpart(reg, reg_class, reg_prefix_regexp, 'prefix')
+  reg_suffix = get_reg_subpart(reg, reg_class, reg_suffix_regexp, 'suffix')
+
+  # Register renaming.  In order to uniquify FileCheck variable names when
+  # registers are redefined, we employ a renaming scheme, not unlike those used
+  # in OOO hardware.  The first time we see a register of a particular class, it
+  # gets a name consisting of the register class name concatenated with a
+  # per-class counter.  All uses of that register value will use the generated
+  # name.  When a register of a particular class is redefined, we increment the
+  # count and generate a new name, when is then used for subsequent uses of the
+  # register.
+  #
+  # Using register class names generalizes the register names, limiting
+  # differences caused by mere register name changes.
+
+  count_index = reg_class
+
+  # Prefix with register class because "mm" appears in two classes.
+  rename_index = reg_class + '_' + reg_key
+
+  count = X86_SCRUB_REG_REPLACEMENT_FUNC.class_count.get(count_index, 0)
+
+  # See if this is either a completely new appearance of a register or a
+  # register (re-)definition.
+
+  if rename_index not in X86_SCRUB_REG_REPLACEMENT_FUNC.renamer or reg_def_func(
+      match.string, reg, match_pos
+  ):
+    count += 1
+    name = get_reg_name(reg_class, count)
+    rv = get_reg_definition(name, reg_key, reg_prefix, reg_suffix)
+    common.debug('   Def or new appearance of ' + reg + ', ' + count_index +
+                 ' count = ' + str(count) + ', replacing with ' + rv)
+  else:
+    name = X86_SCRUB_REG_REPLACEMENT_FUNC.renamer[rename_index]
+    rv = get_reg_use(name, reg_key, reg_prefix, reg_suffix)
+    common.debug('   Use of ' + reg + ', replacing with ' + rv)
+
+  X86_SCRUB_REG_REPLACEMENT_FUNC.renamer[rename_index] = name
+  X86_SCRUB_REG_REPLACEMENT_FUNC.class_count[count_index] = count
+
+  return rv
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.mnemonic_regexp = re.compile(
+  r'^\s*(?P<prefix>rep\s+)?(?P<mnemonic>\S+)'
+)
+
+# Most instructions have the destination tied to the source and thus we don't
+# consider such registers defined, in order to preserve register dependency
+# checking.  Match mnemonics known to define register and not to have tied
+# registers.  Note that this also prevents a "def" for instructions that only
+# use registers because the last register will be considered "tied" even though
+# it isn't really a def.  "cmov" is considered tied, in that the original value
+# of the destination is also a source as the result can be the original value.
+#
+X86_SCRUB_REG_REPLACEMENT_FUNC.noclobber_def_op_regexp = re.compile(
+  # vfm* clobbers a source.
+  # vcomis[sd] does not define an operand.
+  # fp compare with p suffix pops the stack, so consider the register defined.
+  # Others are either unary operations or have more than two operands.
+  #
+  # FIXME:
+  # Some imul forms do not clobber the source register.
+  # pcmp[ei]strm clobbers the first source if it is xmm0.
+  r'^(andn|cvt|bextr|bls|bs[rf]|bzhi|extr|f[ui]?comi?(?<=p)|insert|j|k|ld|' \
+  r'lea|lz|v?mask|mov|mulx|pabs|pcmp[ei]str|pdep|pext|phmin|pins|pmov|pop|' \
+  r'rcp|rd|ror|round|rsqrt|sarx|shlx|shrx|sqrt|tz|v(?!fm|fn|co)|wr)'
+)
+
+# Note that GPR patterns could match nonsensical things like "ebl" but we
+# assume registers are named correctly.
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns = {
+  'GPR'  : r'([abcd]|[sd]i|r[0-9]+|bp)',
+  'X87'  : r'(mm[0-7]|st\([0-7]\))',
+  'VEC'  : r'(mm[0-9]+)',
+  'MASK' : r'(k[0-9]+)',
+  'SEG'  : r'([cdsefg]s)'
+}
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_regexps = {
+  'GPR'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns['GPR']),
+  'X87'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns['X87']),
+  'VEC'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns['VEC']),
+  'MASK' : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns['MASK']),
+  'SEG'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_key_patterns['SEG']),
+  }
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns = {
+  'GPR'  : r'^(%[er]?)',
+  'X87'  : r'^(%)',
+  'VEC'  : r'^(%[xyz])',
+  'MASK' : r'^(%)',
+  'SEG'  : r'^(%)'
+}
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_regexps = {
+  'GPR'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns['GPR']),
+  'X87'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns['X87']),
+  'VEC'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns['VEC']),
+  'MASK' : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns['MASK']),
+  'SEG'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_prefix_patterns['SEG']),
+}
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns = {
+  'GPR'  : r'([hlbwdx]?)$',
+  'X87'  : r'()$',
+  'VEC'  : r'()$',
+  'MASK' : r'()$',
+  'SEG'  : r'()$'
+}
+
+X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_regexps = {
+  'GPR'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns['GPR']),
+  'X87'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns['X87']),
+  'VEC'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns['VEC']),
+  'MASK' : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns['MASK']),
+  'SEG'  : re.compile(X86_SCRUB_REG_REPLACEMENT_FUNC.register_suffix_patterns['SEG']),
+}
+
+# Reset the state of the matcher.
+def X86_SCRUB_REG_RESET():
+  X86_SCRUB_REG_REPLACEMENT_FUNC.renamer = dict()
+  X86_SCRUB_REG_REPLACEMENT_FUNC.class_count = dict()
+
+# Convert register names to FileCheck variables based on register class.
+# Regexps must have group delimeters to extract the register name using group 1.
+#
+# asm - The asm string to scrub
+# reg_regexps - List of regular expressions to match a register
+# reg_class_map - Map from regular expression pattern to a list or two items:
+#   item 0 - The name of the register class used to form a FileCheck variable
+#   item 1 - A count of how many definitions of registers in the class we've
+#            seen
+# reg_def_func - A function that, given the matching asm line, the matched
+#                register and 2-tuple of match start-end position, returns True
+#                if the match is a register definition
+#
+def scrub_reg_names(asm, reg_regexps, reg_replace_func, reset_func):
+  # This gets called for each match that occurs in a line. We transform
+  # registers we haven't seen into defs, and registers we have seen into uses.
+  def transform_line_regs(match, reg_replace_func):
+    return reg_replace_func(match)
+
+  reset_func()
+
+  lines = asm.splitlines()
+  for i, line in enumerate(lines):
+    common.debug('Line:' + line)
+    for reg_regexp in reg_regexps:
+      lines[i] = reg_regexp.sub(reg_replace_func, lines[i])
+    common.debug('New line:' + lines[i])
+  return '\n'.join(lines)
+
 def scrub_asm_x86(asm, args):
+  if getattr(args, 'scrub_reg_names', False):
+    # Replace register references with FileCheck variables.
+    asm = scrub_reg_names(asm, X86_SCRUB_REG_REGEXPS,
+                          X86_SCRUB_REG_REPLACEMENT_FUNC, X86_SCRUB_REG_RESET)
+
   # Scrub runs of whitespace out of the assembly, but leave the leading
   # whitespace in place.
   asm = common.SCRUB_WHITESPACE_RE.sub(r' ', asm)
   # Expand the tabs used for indentation.
   asm = string.expandtabs(asm, 2)
 
   # Detect shuffle asm comments and hide the operands in favor of the comments.
   if getattr(args, 'no_x86_scrub_mem_shuffle', True):
def scrub_asm_riscv(asm, args):
   asm = common.SCRUB_WHITESPACE_RE.sub(r' ', asm)
   # Expand the tabs used for indentation.
   asm = string.expandtabs(asm, 2)
   # Strip trailing whitespace.
   asm = common.SCRUB_TRAILING_WHITESPACE_RE.sub(r'', asm)
   return asm
 
 def scrub_asm_lanai(asm, args):
+  if getattr(args, 'scrub_reg_names', False):
+    asm = scrub_reg_names(
+      asm,
+      LANAI_SCRUB_REG_REGEXPS,
+      lambda match: scrub_reg_get_reg_replacement(
+        match, LANAI_SCRUB_REG_REG_CLASS_FUNC, LANAI_SCRUB_REG_REG_DEF_FUNC
+      ),
+      scrub_reg_reset
+    )
+
   # Scrub runs of whitespace out of the assembly, but leave the leading
   # whitespace in place.
   asm = common.SCRUB_WHITESPACE_RE.sub(r' ', asm)
   # Expand the tabs used for indentation.
   asm = string.expandtabs(asm, 2)
   # Strip trailing whitespace.
   asm = common.SCRUB_TRAILING_WHITESPACE_RE.sub(r'', asm)
   return asm

llvm/utils/update_llc_test_checks.py

def main():
   parser.add_argument('--llc-binary', default=None,
                       help='The "llc" binary to use to generate the test case')
   parser.add_argument(
       '--function', help='The function in the test file to update')
   parser.add_argument(
       '--extra_scrub', action='store_true',
       help='Always use additional regex to further reduce diffs between various subtargets')
   parser.add_argument(
+      '--scrub-reg-names', action='store_true',
+      help='Replace register names with FileCheck variables')
+  parser.add_argument(
       '--x86_scrub_sp', action='store_true', default=True,
       help='Use regex for x86 sp matching to reduce diffs between various subtargets')
   parser.add_argument(
       '--no_x86_scrub_sp', action='store_false', dest='x86_scrub_sp')
   parser.add_argument(
       '--x86_scrub_rip', action='store_true', default=False,
       help='Use more regex for x86 rip matching to reduce diffs between various subtargets')
   parser.add_argument(