This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Remove unused prefixes in llvm/test/CodeGen/X86
ClosedPublic

Authored by mtrofin on Dec 9 2020, 1:10 PM.

Diff Detail

Event Timeline

mtrofin requested review of this revision.Dec 9 2020, 1:10 PM
mtrofin created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2020, 1:10 PM
pengfei added a comment.EditedDec 9 2020, 7:56 PM

I left about 12 tests when I fixed the prefixes issues using the script, because the changes on prefixes will resulted in conflict when re-generating them. I suspected if it is a bug in update_llc_test_checks.py, but I didn't find time to look through. Maybe we can add --allow-unused-prefixes=true for these failed tests as a workaround?

I left about 12 tests when I fixed the prefixes issues using the script, because the changes on prefixes will resulted in conflict when re-generating them. I suspected if it is a bug in update_llc_test_checks.py, but I didn't find time to look through. Maybe we can add --allow-unused-prefixes=false for these failed tests as a workaround?

I actually just undid the re-generation changes, leaving just the unused prefix removal. I'm not sure what the pros/cons to re-generation would be - my reasoning was about "keeping this change scoped". The tests passed, though with a FileCheck with the flag flipped to not allow unused prefixes.

pengfei added a comment.EditedDec 9 2020, 11:20 PM

I left about 12 tests when I fixed the prefixes issues using the script, because the changes on prefixes will resulted in conflict when re-generating them. I suspected if it is a bug in update_llc_test_checks.py, but I didn't find time to look through. Maybe we can add --allow-unused-prefixes=false for these failed tests as a workaround?

I actually just undid the re-generation changes, leaving just the unused prefix removal. I'm not sure what the pros/cons to re-generation would be - my reasoning was about "keeping this change scoped". The tests passed, though with a FileCheck with the flag flipped to not allow unused prefixes.

I'm afraid when pepole change something and need to update the tests, the conflict will confuse them and may spend more time to know what happened. At least we need to remove

; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py

, though I think adding --allow-unused-prefixes=true seems better.
I'd like to see other reviewers opinions.

This comment was removed by lebedev.ri.

I left about 12 tests when I fixed the prefixes issues using the script, because the changes on prefixes will resulted in conflict when re-generating them. I suspected if it is a bug in update_llc_test_checks.py, but I didn't find time to look through. Maybe we can add --allow-unused-prefixes=false for these failed tests as a workaround?

I actually just undid the re-generation changes, leaving just the unused prefix removal. I'm not sure what the pros/cons to re-generation would be - my reasoning was about "keeping this change scoped". The tests passed, though with a FileCheck with the flag flipped to not allow unused prefixes.

I'm afraid when pepole change something and need to update the tests, the conflict will confuse them and may spend more time to know what happened. At least we need to remove

; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py

, though I think adding --allow-unused-prefixes=false seems better.

I think you meant --allow-unused-prefixes=true.

I'd like to see other reviewers opinions.

+1, this is precisely why i think this whole --allow-unused-prefixes=false-by-default endeavor is a horrible idea.

I think you meant --allow-unused-prefixes=true.

Yes, that's what I meant. Thanks for correct me.

mtrofin added a comment.EditedDec 10 2020, 5:01 PM

I think you meant --allow-unused-prefixes=true.

Yes, that's what I meant. Thanks for correct me.

I was not familiar with update_llc_test_checks.py before this point, and, after digging a bit more, I understand @lebedev.ri 's concern - looks like quite a few (3K) of tests in CodeGen (14K or so) use it. So I wanted to understand why removing a prefix used nowhere in the test lead to an incorrect rewrite of some assertions.

I believe I found the cause - ptal D93078. Once that lands, I'll redo this patch.

Separately, am I understanding update_llc_test.checks.py's usage accurately - IIUC, it's basically this:

  • write new RUN line. Add, to FileCheck, a list of prefixes to check
  • write functions
  • run update_llc_test.checs.py => it will add the pertinent asserts to the function(s) added above

I can understand one may add a larger list of labels than necessary when initially authoring a RUN line. Apologies if I'm missing a pain point not obvious to me (given lack of familiarity) - I'd argue that tidying that at this point should be quite straight forward: should the list contain prefixes that end up not being used, FileCheck gives that sub-list; if the outcome is surprising to the developer (i.e. they expected a label be actually used), they get an earlier heads-up than needing to scroll down to where the asserts were inserted; in either case, the fix should be quick (it's in the current change); and the benefit is that what the developer intended is actually checked for.

looks like quite a few (3K) of tests in CodeGen (14K or so) use it. So I wanted to understand why removing a prefix used nowhere in the test lead to an incorrect rewrite of some assertions.

There are more then 6K tests. update_llc_test_checks.py is just one of the update scripts.

Separately, am I understanding update_llc_test.checks.py's usage accurately - IIUC, it's basically this:

  • write new RUN line. Add, to FileCheck, a list of prefixes to check
  • write functions
  • run update_llc_test.checs.py => it will add the pertinent asserts to the function(s) added above

In fact, I usually assign one prefix to RUN line at the beginning and run update script. If there are duplications, I will add a common prefix for them.
For tests have many RUNs and functions, I may do round and round updates to find a relatively optimized combination. Some prefixes may become unused without aware of. Some attempts are not correct, but I'm aware of them since the script will warn the conflict.

lebedev.ri added a comment.EditedDec 10 2020, 11:12 PM

I think you meant --allow-unused-prefixes=true.

Yes, that's what I meant. Thanks for correct me.

I was not familiar with update_llc_test_checks.py before this point, and, after digging a bit more, I understand @lebedev.ri 's concern - looks like quite a few (3K) of tests in CodeGen (14K or so) use it. So I wanted to understand why removing a prefix used nowhere in the test lead to an incorrect rewrite of some assertions.

I believe I found the cause - ptal D93078. Once that lands, I'll redo this patch.

Separately, am I understanding update_llc_test.checks.py's usage accurately - IIUC, it's basically this:

  • write new RUN line. Add, to FileCheck, a list of prefixes to check
  • write functions
  • run update_llc_test.checs.py => it will add the pertinent asserts to the function(s) added above

I can understand one may add a larger list of labels than necessary when initially authoring a RUN line. Apologies if I'm missing a pain point not obvious to me (given lack of familiarity) - I'd argue that tidying that at this point should be quite straight forward: should the list contain prefixes that end up not being used, FileCheck gives that sub-list; if the outcome is surprising to the developer (i.e. they expected a label be actually used), they get an earlier heads-up than needing to scroll down to where the asserts were inserted; in either case, the fix should be quick (it's in the current change); and the benefit is that what the developer intended is actually checked for.

And this is not specific to codegen/update_llc_test_checks.py tests, the workflow is *exactly* the same for opt tests (update_test_checks.py)...

RKSimon added inline comments.Dec 15 2020, 9:37 AM
llvm/test/CodeGen/X86/extract-bits.ll
456 ↗(On Diff #311936)

Please can you regenerate and pre-commit this file with the @PLT fix? Then rebase this patch.

mtrofin updated this revision to Diff 311951.Dec 15 2020, 9:53 AM

rebased after pushing extract-bits's plt change

mtrofin marked an inline comment as done.Dec 15 2020, 9:54 AM
mtrofin added inline comments.
llvm/test/CodeGen/X86/extract-bits.ll
456 ↗(On Diff #311936)

done. I think we want also extract-lowbits.ll

mtrofin updated this revision to Diff 311955.Dec 15 2020, 10:05 AM
mtrofin marked an inline comment as done.

rebased to remove unrelated changes (remaining @plt)

RKSimon added inline comments.Dec 15 2020, 10:15 AM
llvm/test/CodeGen/X86/extract-lowbits.ll
4 ↗(On Diff #311955)

This looks wrong - for instance - @bzhi32_a0 doesn't have any X86 checks.....

mtrofin marked an inline comment as done.Dec 15 2020, 10:36 AM
mtrofin added inline comments.
llvm/test/CodeGen/X86/extract-lowbits.ll
4 ↗(On Diff #311955)

All this patch does is removes unused prefixes - so by the looks of it, @bzhi32_a0 didn't have X86 checks in the first place. Maybe because these other tests that use the X86 label produce conflicting outputs for @bzhi32_a0, case in which update_llc_test_checks does not produce an output for the function for that prefix (this is existing behavior).

We probably need more fixing to update_llc_test_checks. I think you're saying that we want to ensure each function is tested by each RUN line?

@mtrofin Please can you rebase and see if the extract bits tests are fixed now?

mtrofin updated this revision to Diff 312234.Dec 16 2020, 9:14 AM
mtrofin marked an inline comment as done.

rebase. extract-[low]bits.ll are not part of the patch anymore

@mtrofin Please can you rebase and see if the extract bits tests are fixed now?

Yup!

This revision is now accepted and ready to land.Dec 16 2020, 10:46 AM
This revision was landed with ongoing or failed builds.Dec 16 2020, 12:42 PM
This revision was automatically updated to reflect the committed changes.