- User Since
- Jul 1 2015, 10:19 AM (413 w, 3 d)
Feb 9 2022
Feb 7 2022
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.
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.
Jan 31 2022
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.
Updated with bug fixes. Posting so that future visitors will see the change mentioned in the Differential Revision field of the commit message.
Jan 28 2022
Ping. Can we merge this?
Jan 21 2022
Fixed a brown paper bag bug (filter-out was not working).
Jan 19 2022
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.
Jan 18 2022
Fixed non-clobber register def regexp for x86. It was using lookbehind instead of negative lookahead for vector mnemonics.
Jan 14 2022
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.
Jan 13 2022
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.
Jan 12 2022
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?
IIUC, the point of this change is not to alter the behavior for options that have a cl::init, but rather to alter behavior for options that _don't_ have a default provided. Right now, those options don't get reset when ResetAllOptionOccurrences is called. With this patch, options _without_ cl::init should get reset to the default-constructed value of the option type, and options with cl::init get initialized to the default value.
Jan 11 2022
Jan 10 2022
What is the motivation for this change? I can argue for maintaining the current behavior., If I pass a cl::init to an option and call ResetAllOptionOccurrences I would expect that cl::init value to be used to reset the option. There are compiler flows that rely on that behavior.
We do need an X86 test for this.
Jan 7 2022
Dec 2 2021
Oct 20 2021
Jun 23 2021
Jan 15 2021
Jan 11 2021
Updated to main, implemented some suggested changes.
Dec 15 2020
This is still on my TODO list but got pushed aside for a bit due to other issues. I expect to be back on this in the next couple of weeks.
Oct 8 2020
Oct 7 2020
Oct 1 2020
Sep 30 2020
Not my area of expertise but looks fine if the comments from others are addressed.
I don't really have the expertise to approve this. The patch looks fine from a readability standpoint.
This is pretty far afield from my areas of expertise so I can't really comment on the overall approach of this patch. From a purely mechanical/style point of view this seems fine to me.
Make clang-tidy (more?) happy.
Sep 23 2020
Sep 18 2020
Sep 17 2020
Fix one inadvertent change to the original algorithm in update_test_checks.py. This line:
had an extra rstrip in it compared to the original. It was probably an innocuous change but fixing this makes the diff a bit cleaner.
Refactored to pull out most of the --include-generated-funcs processing into common.py.
Enhanced update_test_checks.py to honor --include-generated-funcs and added tests. For fun, did the same for update_llc_test_checks.py. The latter doesn't have complete coverage for all architectures because the machine outliner doesn't run on every backend. I didn't look further into this but we can do so later if desired.
Sep 16 2020
Sep 15 2020
Jul 22 2020
Updated to move the option into common.py. Also had to rework the output loop to account for differences between python 2 and 3.
Jul 7 2020
Jul 6 2020
Fixed various bugs, added tests.
Jul 2 2020
Jul 1 2020
Do we have any tests for these tools? I vaguely recall some discussion about tests but I couldn't find any. I'd like to add tests for this feature if the infrastructure is already there.
Jun 15 2020
Jun 8 2020
Ok, so if test-suite seems.like a good place for such tests, can this change proceed?
May 22 2020
May 18 2020
Getting back to this. From the (very long!) thread on end-to-end testing, people are generally supportive of the idea. The main question is where tests should be located. That question is othogonal to this patch. We currently use the functionality of this patch downstream and I'm guessing others would also find it useful. Since the idea of end-to-end testing seems to be supported in the community, can we merge this patch and then have a follow-up discussion about where such tests should live upstream? Getting this merged now would allow others to experiment with/use the functionality as discussion about where to place end-to-end tests continues.