- User Since
- Jul 1 2015, 10:19 AM (273 w, 4 d)
Wed, Sep 23
Fri, Sep 18
Thu, Sep 17
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.
Wed, Sep 16
Tue, Sep 15
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.
Apr 22 2020
Mar 2 2020
Feb 28 2020
This appeared using a quite old version of LLVM with an out-of-tree target and I'm having trouble getting a valid testcase out that runs with the latest LLVM/bugpoint. The code in question is exacly the same in the old and current LLVM so the bug still exists currently but I haven't yet been able to generate a testcase. Thought I would at least put this up for review. I'm not entirely confident current master could get into this situation but it seems wise to guard against it.
Feb 18 2020
Feb 3 2020
LGTM. I did something similar in my local copy that I was going to upstream but I added a switch for the user to choose where to place checks (declaration, definition or both). I only added the switch because I wasn't sure whether the changed behavior was intended. I'm fine just placing checks on definitions as I don't have a need to put them on declarations.
Dec 17 2019
Dec 16 2019
Updated to latest master.
Ping. This is ready for another review.
Dec 3 2019
Added comment explaining what a write-combining buffer is and one possibility of how to use this information.
Ok, I think I've addressed all the comments so this is ready for another review. Thanks!
Nov 1 2019
Oct 30 2019
LGTM. This is useful functionality.
Oct 29 2019
This revision avoids the more general use of register scavenging, opting instead for a local register scavenger which can operate in backward mode, which doesn't need up-to-date liveness information. This seems safer to me, avoiding lots of potentially unknown pitfalls in the X86 backend.
This causes a couple of tests to fail due to the X86 backend not keeping liveness information up-to-date. My understanding is that the liveness bits should go away. Currently PEI uses RegisterScavenging::forward which is commented as being not preferred. The better option is to use RegisterScavenging::backward which doesn't need to rely on liveness information. However, PEI iterates through the basic block in a forward manner, so using RegisterScavenging::backward could be expensive.
Oct 28 2019
This likely needs some work. I wanted to get it up early because it includes a rather significant change, the first use of register scavenging in the X86 backend as far as I'm aware. If there is a better way to do this I'm all ears.
Oct 17 2019
Oct 10 2019
Does this subsume the goal of D68153? If so I am happy to abandon that revision. D68153 attempts to solve the problem of a CHECK-LABEL matching a function call instead of the start of a function definition. It looks like with --function-signature the CHECK-LABEL will include the arguments in the label pattern which should be enough to disambiguate it from a call to the function. Do I have that right?
we might say something like:\return the number of write-combining buffers. A write-combining buffer is a per-core resource used for collecting writes to a particular cache line before further processing those writes using other parts of the memory subsystem.
Oct 9 2019
Oct 8 2019
Oct 7 2019
For some reason the commit did not auto-update this. Closing with commit r373912/a14ffc7eb741de4fd7484350d11947dea40991fd.
Oct 4 2019
Oct 1 2019
My thinking on this is now that we have the monorepo and that the monorepo will become the canonical source after the conference this month, it's much more feasible to create end-to-end tests. They could live in a subdirectory of the monorepo root. They wouldn't be largish things like in test-suite but rather more focused tests that ensure some behavior works in the context of the entire tool pipeline.
We also need to use the asm check generator so that LABEL expressions are generated correctly.
Sep 30 2019
The more I think about this, the more I do think this should use from __future__ import print_function.
Should this use from __future__ import print_function to avoid someone accidentially printing arguments as a tuple?