[PATCH] D116832: [UpdateLLCTestChecks] Allow replacing register names with variables

David Greene via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 21 13:44:11 PST 2022


greened added a comment.

In D116832#3257235 <https://reviews.llvm.org/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 <https://reviews.llvm.org/diffusion/L/> and %R2 <https://reviews.llvm.org/source/clang-tools-extra/> 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.

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

Because we might still want to scrub names after filtering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116832



More information about the llvm-commits mailing list