- User Since
- Jan 28 2016, 8:30 AM (64 w, 4 d)
Fri, Apr 21
Looks very good now! Thanks!
Thu, Apr 20
Thank you for doing this! I really need it.
Thu, Apr 13
Wed, Apr 12
For the second assert it may be the case for iterator invalidation, though I haven't checked.
Mon, Apr 10
Fri, Apr 7
Thu, Apr 6
The following tests assert with this (and predecessors) patches:
Wed, Apr 5
Tue, Apr 4
First part of comments related only to C++ issues
Fri, Mar 31
If SU(i) uses register produced by SI(j):
I may miss something, but it looks that you can build data edges when building a superdag consisting of blocks. Incoming data edges would be liveins, outcoming - liveouts.
In general, I think moving instructions just to use standard RP tracker to discover liveins/liveouts isn't a good idea. It isn't only slow but doesn't look reliable too. Why not discover these sets using DAG directly?
I didn't debugged it and I don't know why you decided so.
I ran lit tests with sished with ShouldTrackLaneMasks=true enabled by default with this patch, the following tests asserted:
Wed, Mar 29
Tue, Mar 28
Axel, thanks for the update.
This looks elegant, mine was longer :), thanks!
Ok, I understood SIScheduleBlockCreator::scheduleInsideBlocks() moves instructions to actually get LiveIn and LiveOut set for a block, but this is rather heavy. Have you thought about getting those using DAG directly, not regpressure tracker? By the common sence the dependencies between blocks correspond to that liveness info. There is a problem however: LiveIn and LiveOut dependencies aren't modelled for boundary SUs. I have local patch that build such dependencies - scheduling region LiveIns edges comes from EntrySU, LiveOut - to ExitSU. Another problem - dependency edges doesn't have lanemask, need to think how to deal with this.
Why SIScheduleBlockCreator::scheduleInsideBlocks() actually move instructions? Why it isn't done on the final scheduling?
Mon, Mar 27
Sorry but I give up reviewing this. Your code looks like after "inline all" pass. Can you refactor common parts into functions with meaningfull names?
Mar 24 2017
Mar 23 2017
Mar 22 2017
Mar 21 2017
Mar 20 2017
Restored function order
I optimistically moved dump function down in GCNRegPressure.cpp and all comments got out of sync with the source, sorry.
Added tests + per review updates.
Mar 17 2017
Then in my example, what is the result of this strategy ? Does it avoid scheduling SU 6 late ?
From you example it's not clear how the following SUs relate: SU6 <-> SU7, SU9 <-> SU7, SU9 <-> SU8
As for including sisched I have patch to include it into this, though its a bit outdated and should be updated.
I think one blocker is sisched doesn't support yet when subRegLiveness is enabled. I'm on it.
I have several sisched patches pending review. Would be great if you could take a look in order to have them merged.
Mar 16 2017
Hi Axel, thanks for reply!
Feb 28 2017
Ok, it's just not that easy to follow this in GCNMaxOccupancySchedStrategy::initialize.
I'm just a bit confused: what gives scheduler more registry freedom on rescheduling run?