- User Since
- Jul 1 2015, 10:19 AM (224 w, 1 d)
Thu, Oct 10
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.
Wed, Oct 9
Tue, Oct 8
Mon, Oct 7
For some reason the commit did not auto-update this. Closing with commit r373912/a14ffc7eb741de4fd7484350d11947dea40991fd.
Fri, Oct 4
Tue, Oct 1
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.
Mon, Sep 30
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?
Fri, Sep 27
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.
Thu, Sep 26
Thu, Sep 19
Wed, Sep 18
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. :)
I can't really comment on the correctness of this but other than the one comment I'd like to see added, LGTM.
Aug 1 2019
This was accepted. Did it land?
I wouldn't really worry about optimizing this; dynamic stack allocation is rare in most C and C++ codebases, and one integer register likely doesn't matter much.
Jul 31 2019
What's the status of this?
Jul 24 2019
Jul 18 2019
Jul 17 2019
What about downstream users that have added directories in their local forks? Having git suddenly ignore them would be surprising. We are in that situation.