Skip to content

Conversation

Quincunx271
Copy link
Member

Implement RP-preserving ILP graph transformations. Also implement the ability to choose where graph transformations are applied (before or after the heuristic).


This is intended to bring all of my current state of graph transformations into master.

@Quincunx271 Quincunx271 added the enhancement New feature or request label Mar 8, 2021
@Quincunx271 Quincunx271 force-pushed the feature-occupancy-preserving-ilp-gt branch 5 times, most recently from a898671 to 4294980 Compare March 8, 2021 07:13
@Quincunx271 Quincunx271 force-pushed the feature-occupancy-preserving-ilp-gt branch 3 times, most recently from 9b1a1d5 to 61258ba Compare March 23, 2021 01:09
Quincunx271 and others added 17 commits June 2, 2021 17:50
The graph transformation edges break the SeqListScheduler.
The previous UpdateSetupForScheduling(...) function did too much and
also clobbered useful information. This changes the code from calling
that after each graph transformations pass to having each pass declare
what updates it needs, performing only those updates.

Removed behavior from removing the call to UpdateSetupForScheduling:
 - No longer re-allocating all of the info inside each SchedInstruction
 - No longer re-setting (redundantly) all of the info in each
   SchedInstruction
 - No longer recomputing lower and upper bounds. If we have already
   computed that, we don't want to lose the previously-computed values
Rather than hardcoding the application before or after the heuristic,
make it a runtime option.

Applying graph transformations before the heuristic has the advantage
that the heuristic now has a simpler problem to solve, and thus is more
likely to find an optimal solution. Furthermore, the lower bound will be
tighter.

Applying graph transformations after the heuristic has the advantage
that we don't waste time running graph transformations for problems that
are already easy; if the heuristic scheduler proves the schedule
optimal, we skip graph transformations altogether.

Another option is possible: we could do the heuristic first, then if the
schedule is not known to be optimal, run graph transformations (as in
GT after heuristic), but then re-run the heuristic so that we can
potentially skip enumeration. This option is NOT implemented.
The SeqListScheduler is unlikely to find an optimal scheduler, so it is
almost certainly better to do graph transformations "before heuristic",
meaning---in this case---before the lower bound calculation.
Enables calculating the amount of time these operations took.
Often, it was confusing the direction of the added edge. This fixes it
by reading the from/to directly from the added edge.
@Quincunx271 Quincunx271 force-pushed the feature-occupancy-preserving-ilp-gt branch from b46c109 to c0c5b25 Compare June 3, 2021 00:14
@Quincunx271 Quincunx271 force-pushed the feature-occupancy-preserving-ilp-gt branch 2 times, most recently from 35b4970 to 9abde54 Compare June 15, 2021 20:23
@Quincunx271 Quincunx271 force-pushed the feature-occupancy-preserving-ilp-gt branch from 9abde54 to 7eba7b3 Compare June 15, 2021 20:31
The previous conditions could remove an edge (x, y) even if that edge
was the reason for the critical path between x and y. These new
conditions only consider the path through the newly added edge to avoid
that issue.
high_resolution_clock is system_clock in libstdc++.
B&B is unlikely to find significant benefit for extremely large regions,
once the exponentially larger search space is taken into account. As
such, it makes sense to have a knob to disable this scheduling if the
region is too large.
The previous name was too generic. This change renames the function to
clearly specify what it does.
@Quincunx271
Copy link
Member Author

Any last thoughts on this PR, or is it ready to submit?

@jrbyrnes
Copy link
Contributor

Any last thoughts on this PR, or is it ready to submit?

Looks fine to me

@Quincunx271 Quincunx271 merged commit 6a3dbe7 into CSUS-LLVM:master Oct 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants