User Details
- User Since
- Aug 19 2013, 3:30 PM (386 w, 6 d)
Thu, Jan 14
A sys::SmartMutex equivalent of this would LGTM. Let me know if there's a reason we should stick to std::mutex
Mon, Jan 11
Mostly LGTM but I'd rather move the vector_extract back to SelectionDAGCompat.td as having it there doesn't break anything.
Thu, Jan 7
Wed, Jan 6
LGTM, Thanks
Dec 16 2020
Thanks!
Dec 15 2020
But since everyone else have had to do this for other targets, I suppose I will be forced to do the same.
Dec 9 2020
LGTM
Dec 7 2020
Dec 2 2020
LGTM with @gjain's suggestions. I think SIRegisterInfo.cpp could also propagate MCRegister a bit further if you wanted but I didn't check all the users of SubReg
Oct 16 2020
Peng asked me to commit this off-list
Oct 5 2020
LGTM
Sep 8 2020
I've only read up to Formal Rules so later sections might change things but I figure it's potentially useful to see a readers thoughts mid-read. I'm pretty sure I've misunderstood the anchor intrinsic based on what I've read of the doc and comments so far.
Sep 4 2020
Sep 3 2020
Aug 27 2020
Aug 14 2020
LGTM
Aug 4 2020
Aug 3 2020
Make standalone clang builds work correctly. LLVM_SOURCE_DIR isn't set for those
Small naming change to match that directory
Last one our own testing hit: Fix the case where lack of debug info means we didn't extract dsyms
Fix the non-LTO path. It wasn't externalizing the debug info in single-slice builds
Jul 28 2020
Remove external- prefix
Jul 27 2020
Jul 24 2020
Attempt to fix the windows-specific failure by using posix-style path::append()
- Comment on the emit+move too
- Add comment referencing the bug
Jul 20 2020
Jul 19 2020
tools/lto/hide-linkonce-odr.ll failed on my test run but it seems to be down to my system rather than the compiler (a library is genuinely missing). Will check if it fails without this change too
Jul 15 2020
Jul 13 2020
Yeah, there isn't really a better way to do it as there's no dependency tracking in the importer. GIMatchDAG can track exactly what needs to be available for the predicate to be testable (making it just an issue of how to represent that in the source) but we aren't using that in the importer.
Jul 7 2020
Jul 6 2020
I was worried for a moment that we'd be losing the ability to print between all machine passes but it looks like -print-after-all covers that now (I don't think that was always the case). So long as we aren't losing any inter-pass dumps this LGTM but I'd suggest giving it a few days to see if anyone was using this in a way that isn't evident from the tests.
Could you add a test case or point us at a example of an existing test that goes wrong? The description in the commit message is unlikely to be the full story as we already cover loads with non-null MemoryVT's. My best guess is you are attempting to use builtin predicates and custom predicates together. I don't see a reason why that shouldn't be allowed but it's not something that was intended as the goal was aiming to fully remove the custom C++ from the tablegen headers so that tablegen could do some transformations on sextload/zextload and similar to fix DAGISel vs GlobalISel modelling mismatches.
Jun 29 2020
From that it *sounds* like a DBG_VALUE of an undef vreg doesn't make sense?
@vsk + @aprantl: I believe this is going to need an exception for DBG_VALUE. Could you confirm if that's correct?
Jun 22 2020
LGTM
Jun 16 2020
Add only-enable-rule and make it interact with disable-rule correctly.
Jun 15 2020
Jun 12 2020
Remove a bit of the next patch that snuck into this one while organizing the patches
Just to give you some context and an overview of the direction, we have some hacks we use to make our LLVM dylib smaller by omitting subcomponents of LLVM that we don't actually use in practice. This is part of a small series of patches to try to eliminate these hacks by rounding out llvmbuild's support for optional libraries. This patch allows libraries to be included by default and optionally disabled, and it will be followed by a small bugfix for --enable-optional-components, and then the addition of an optional_libraries to go with the existing required_libraries.
Jun 11 2020
LGTM
Jun 10 2020
Jun 9 2020
LGTM
I'm not sure this is the correct instance to remove; now the visible
ordering is different. Now you will typically see the one erased
instruction message before all the new instructions in order. I think
this is the more logical view of typical legalization changes,
although it's mechanically backwards from the normal
insert-new-erase-old pattern.
Jun 3 2020
LGTM
Jun 2 2020
LGTM