- User Since
- Mar 19 2018, 2:57 AM (43 w, 6 d)
Thu, Jan 17
Use an ArrayRef rather than a SmallVectorImpl
Hi Bjorn, this is highly useful and relevant to my interests,
Wed, Jan 16
Thanks for the reviews,
This was superseded by... well... trying to kill off collectDebugValues, basically. It's a general function that gets used in very specialised circumstances.
This was superceeded by D56265.
Tue, Jan 15
Shift DBG_VALUE updating to a MachineRegisterInfo helper
Trim and revise MIR test as per Björn's comments.
Mon, Jan 14
Revise a comment (missed in previous rev, whoops)
Use enumeration and explicit function arguments to disambiguate debug and regular register readers
Revise comment for mergeChangesDbgValue
Fri, Jan 11
NB, speaking directly to Carlos yesterday he approved of the cleanup. I'll likely land this today or Monday.
Fri, Jan 4
Pass MI reference to ReadRegister, avoiding the need for more assertions.
Here's a further revision. Two significant changes:
- Because DBG_VALUEs of either the source or destination register can be resurrected by coalescing, check both,
- There's now no attempt to check whether the two registers refer to the same value number.
Thu, Jan 3
On the topic of coalescing physical registers, it appears the liveness test is well defined in joinReservedPhysReg. However while absorbing all of this, I've realised that dead DBG_VALUEs of both src and dst registers can be resurrected when their intervals are joined. I'll attempt to generalise further...
Thanks for the review,
Sat, Dec 29
Target only DBG_VALUEs that are definitely resurrected with a different def by register coalescing.
Hmmm. In retrospect, aiming to cover all cases where there's a def of the dest-reg in between the last src-def and the DBG_VALUE means considering control flow, which I haven't done.
Dec 10 2018
Dec 7 2018
Correct a comment, whoops.
Remove address-space-zero filter on emitting zero-bit-value nulls
In a test, alter the fragment that two dbg.values refer to. I believe they were incorrect in the first place but silently ignored.
Dec 6 2018
Un-WIPed this revision which should be ready for review now: added llvm-commits, reviewers, and the like.
Dec 5 2018
Looks good; one observation is that if we have N dbg.value's of a variable, we'll end up with N dbg.value(undef)'s of that variable in the output. Ideally we'd only emit one per variable.
Dec 4 2018
Dec 3 2018
Nov 28 2018
Many thanks for the reviews, all.
Simplify DebugLoc assignment, correct a comment
Always assign merged location to merged terminator; update merged phi's to use the selected DebugLoc or nothing.
Update makes this clang-format compliant
Nov 19 2018
Nov 2 2018
Rewrite comments, use DenseMap<u, TinyPtrVector> instead of multimap
Nov 1 2018
Because it's not completely clear in the summary: the reliance on DBG_VALUEs following the insn being sunk is caused by performSink's use of MachineInstr::collectDebugValues
Oct 1 2018
Sep 28 2018
Fixed concurrently by r343282!
Sep 27 2018
Sep 21 2018
LGTM -- obviously this isn't an ideal situation, but the pthreads/OS-threads abstraction isn't supposed to be un-peeled anyway.
Aug 28 2018
Aug 13 2018
Aug 3 2018
Aug 1 2018
This revision works just as well as the previous, but keeps "rename" behaving the same. Some future refactor could introduce a "move" function, this is the minimum change for now.
Jul 31 2018
Thanks for the report, it looks like just adding the "copy between volumes" flag to windows' rename was insufficient -- a preceding rename attempt (with slightly different semantics) needs to fall through to it.
Jul 26 2018
That's 1 Unsupported 43 Passes (apparently I can't count).
LGTM, I get 1 Unsupported (due to Darwin) and 44 successful passes when running lit over the dsymutil\X86\ tests, Windows 10 with a MSVC 2015 build environment. No failures.
Jul 25 2018
Committed in r337929
Jul 24 2018
Hi Dean et al,
Jul 19 2018
ping @reames , does the inline comment clear up the question?
Jul 2 2018
Jun 21 2018
Jun 19 2018
Add review response which (I think) clears up some confusion.
Jun 12 2018
Ping, partially for rebase, mostly because the phab-workflow is unclear to me (see immediately previous comment).