User Details
- User Since
- Jul 1 2015, 10:19 AM (289 w, 5 d)
Fri, Jan 15
Mon, Jan 11
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:
output_lines.append(input_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
Added tests.
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.
Ping?
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
@jdoerfert @hfinkel should I consider Johannes' comment a LGTM? This has been waiting for two months now.
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.
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
LGTM.
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.
LGTM.