Fixed Bug 41532 - update_test_checks does not actually handle block names. Also rerun reassociate-after-unroll.ll.
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/test/Transforms/PhaseOrdering/reassociate-after-unroll.ll | ||
---|---|---|
1 | Is that what the script produces? |
llvm/test/Transforms/PhaseOrdering/reassociate-after-unroll.ll | ||
---|---|---|
1 | Do you mean this line, the original LIT test, or the modified LIT test? |
llvm/test/Transforms/PhaseOrdering/reassociate-after-unroll.ll | ||
---|---|---|
1 | Ah, so it's https://bugs.llvm.org/show_bug.cgi?id=41532 |
llvm/test/Transforms/PhaseOrdering/reassociate-after-unroll.ll | ||
---|---|---|
1 | I will address the issue in the script at a later date and try to provide a fix for PR41532, but for now I have this test case failing unnecessarily in an out-of-tree target. So I’d like to proceed with the interim fix to the test case for the time being. |
llvm/utils/UpdateTestChecks/common.py | ||
---|---|---|
139–142 | I am trying to figure out how to match all variables which doesn't have prefix "label". |
I cannot think of any clean way to identify labels, there are three ways that label can be:
- at the start of a basic block.
- follow by "label".
- incoming blocks in phinode.
@MaskRay Do you feel strong to limit the change only to label? If so, can you give me some guidance on how to do it?
It depends on how other reviewers think about it... If it is suggested keeping the diff minimum is a desired property, you probably have to parse phi and label constructs..
It depends on how other reviewers think about it...
Any thoughts? I prefer to keep the script clean and simple, although the one time change to the LIT tests will not be minimal.
I'm not sure I see the value in this change in either implementation. Changing block names seem to be a pretty niche issue (haven't ever run into this myself) and I don't think handling them in update_test_checks is worth the churn it will cause.
Maybe this could be put behind a flag and only used in the few instances where it is needed?
@nikic Thanks for the suggestion. I personally ran into the issue that reassociate-after-unroll.ll failed due to the different in basic block name, after modifying the O2 pass pipeline. And modifying the script, was the suggested way to solve the failure. I am willing to put this change behind a flag if that's preferred, but it maybe hard for user to know when to use the flag, or even know the existence of it.
@nikic As suggested, I added a flag to decide if to generate basic block names as variables.
There is still a great amount of diff. I am afraid this cannot be accepted. Can be hold off on this until block name changing becomes less niche?
Is that what the script produces?