- User Since
- Jul 1 2015, 10:19 AM (238 w, 4 d)
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?
Sep 27 2019
What happens when this is run with python 2 in the path? Should this explicitly run via python3?
I also don't see the value in this. With autogenerated checks, the name of the instructions shouldn't be required to tell if the test is getting the correct behaviour and preserving the names makes test checks much more fragile.
Sep 26 2019
Sep 19 2019
Sep 18 2019
Sep 5 2019
Sep 3 2019
Since I don't see anything strange that was introduced by this patch, LGTM.
Aug 27 2019
Aug 20 2019
Aug 19 2019
Removed casts, default constructors, added all operators where it makes sense (unary *, ->, ->*, unary &, comma,  and () not added because a default return type is not obvious), placed operators in their own namespace to avoid collisions, rewrote example, updated tests.
Aug 16 2019
Aug 15 2019
Aug 14 2019
Aug 13 2019
LGTM, though are we sure this is true for all targets? The comments in the referenced patch only consider X86. I'm pretty sure it is true for common architectures like AArch64 but I'm not as sure for more exotic things.
Oops, I missed that this landed already. Perhaps a later commit can improve the debug message.
This LGTM but I think someone else should probably sign off on it as well.
Aug 2 2019
I wonder if this should have a test that ensures we generate VL-scaled addressing modes for SVE object addressing. If there's not enough codegen yet to emit the asm, then we should probably add such a test when we can. After all, it's the stated goal of this patch. :)