- User Since
- Aug 19 2013, 3:30 PM (363 w, 7 h)
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
Tue, Jul 28
Remove external- prefix
Mon, Jul 27
Fri, Jul 24
Attempt to fix the windows-specific failure by using posix-style path::append()
- Comment on the emit+move too
- Add comment referencing the bug
Mon, Jul 20
Sun, Jul 19
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
Wed, Jul 15
Mon, Jul 13
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.
Tue, Jul 7
Mon, Jul 6
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?
Jun 22 2020
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
Jun 10 2020
Jun 9 2020
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
Jun 3 2020
Jun 2 2020
Jun 1 2020
LGTM once all other reviewers are happy with this patch.
May 29 2020
May 19 2020
Thanks for working on this. I had a couple inline comments.
May 18 2020
May 7 2020
I'm inclined to agree that the patch series as-is doesn't really warrant the iterators as the interface as no callers have been updated. However, I also don't see much that's iterator specific (ULEBifier would be roughly similar code leaving the iterator portion as trivial wrappers on the ULEBifier) and there are a few places (particularly in tablegen) that are emitting LEB's into containers where the loop to add bytes one by one is just noise and something like std::copy(to_uleb(...), std::back_inserter(Table)); would be somewhat nice. The loop could easily be hidden in something like append_uleb(Table, ...) though I don't think there's a strong argument for (or against) iterators.
May 5 2020
Apr 29 2020
Apr 28 2020
LGTM but double check -verify-machineinstrs works with -run-pass
Apr 27 2020
I don't think it's safe to remove Support since llvm/lib/TableGen/CMakeLists.txt doesn't mention it but adding TableGen to the existing list would LGTM
Apr 21 2020
Apr 17 2020
I currently don't have an in-tree test case for this but it should be possible to construct one. Essentially it needs CSE enabled, and needs two instructions that need legalization and emit a common instruction during their legalizations with identical constraints (to avoid the copy) and have conflicting debug locations. I'll try to make an AArch64 test case when I get chance.