Fri, Oct 23
Thu, Oct 22
Jay, Matt do you have objections with this patch?
Wed, Oct 21
Fixed formatting issue
Tue, Oct 20
Fixed formattind and lint issues.
Mon, Oct 19
Added test, more review issues fixed.
Fri, Oct 16
It should be s_setpc_b64 at this point and it is a terminator and branch. Although I am not sure it can be detected as an EXEC change.
Wed, Oct 14
Per review fixes.
Sun, Oct 11
I've found the case when execMayBeModifiedBeforeAnyUse randomly leads to a coredump, which is hard to debug. Most likely it's because an instruction beyond the end of a basic block is accessed. This means that the first loop calculates some instructions twice and I was wrong assuming use_nodbg_instructions doesn't repeat them. In fact there is no code in MachineRegisterInfo::verifyUseList that ensures that uses belonging to one instruction should be sequent in the use list nor the traces of such ordering can be found in MachineRegisterInfo::addRegOperandToUseList. I'm going to fix this code.
Sep 24 2020
If that piece of code turns out to be mandatory, we'll find out soon enough and we would get a test case :).
Sep 23 2020
Sorry, I had to explain the context around the modified code.
Sep 22 2020
Sep 7 2020
Aug 31 2020
Honestly, I have no idea one way or another. I'm leaning toward @arsenm's theory that the implicit def may be needed in case the full register is never fully covered.
But I would need to dig deeper into this.
Rebased, updated per review comments.
Aug 20 2020
Can you remove the commit message from the previous commit from this message? I found it confusing to read it here
Aug 18 2020
Jul 23 2020
Ok, let's keep it simple, no much benefit with maps. LGTM.
Overally looks good
Jul 15 2020
I have no objections but I'll ask Dmirty to check this from asm/dasm side.
Jul 14 2020
It would help if 9d7bc0874cf20f44cd331c77f5a003b4c4b262bd had a test...
I'm somewhat suspicious, since I have seen cases where the implicit def is needed in cases where the full register is never fully covered. However, it's possible this is still a leftover from before DetectDeadLanes was added
Jul 10 2020
Jul 7 2020
Given than the condition here is rare, I'm ok with the patch, reworking undef handling in scheduler is a massive work.
I understood your patch. Generally I think patching LIS with cleared undef flags ins't right at first place because the semantic of register lifetime is ruined. After the first move there should be an undef flag set at the %1.sub2 = IMPLICIT_DEF instruction which would break lives of all subregs live at this point. Can we drop updating LIS during scheduling and recreate it from scratch? Or may be fully recreate only the intervals for the registers involved in moves when the undef flag is patched after scheduling?
Can you please add a LiveInterval dump (possibly truncated) for the test before and after each move to this review? It's a bit hard to follow what happens there.
Jul 3 2020
Jul 2 2020
Update before commit: used isIdenticalTo, rebased.
Jun 26 2020
Rebased, added check if use is Src0 or Src1
Indeed, thanks Jay, updated.
Jun 25 2020
Rebased, per review issues fixed, moved VNInfo::print definition ot of class.
split to parts
- skip multiple per instruction DPP register usage.
- don't combine when DPP register is used as part of superreg/supersubreg.
I had to refactor the code to fix the first issue,
Would it make sense to split this patch into two or three? Refactoring, fix bug 1, fix bug 2?
Rebased, per review issues fixed:
Jun 24 2020
Jun 20 2020
Jun 9 2020
Updated patch. Everything is done except I decided to left readsM0 check for the no-ret atomics case.
Jun 6 2020
The SI_INIT_M0 is still used for instructions that I mention in hasNonDefaultM0. Comments say it was introduced to produce S_MOV_B32 m0 so the CSE could join them.
Jun 5 2020
May 29 2020
May 26 2020
May 15 2020
May 6 2020
May 5 2020
Apr 27 2020
Mar 20 2020
Mar 17 2020
LGTM, assuming Matt's concern is addressed.
Mar 4 2020
I cannot follow all the consequences of adding the landing pad, but this looks a robust solution since it's hard to find appropriate insertion point for s_or_saveexec instruction in the beginning of SI_ELSE constaining block.
Feb 27 2020
Feb 18 2020
Jan 27 2020
Jan 24 2020
Jan 21 2020
Dec 12 2019
Almost LGTM. Do you need those liveins reorderings?
Dec 6 2019
Looks good, but the test would be nice to have.
Nov 26 2019
Nov 19 2019
updated the diff per comment. Used utils/update_llc_test_checks.py tool to update autogenerated test.
Nov 18 2019
added test fix.
Look mostly good, but can you split this change into one that relates to DPP and another that disables asm only instructions?