Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aco better ready list #172

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

JoshHuttonCode
Copy link

@JoshHuttonCode JoshHuttonCode commented Oct 11, 2021

Factor key computations out of the ready list into the KeysHelper class, and implements and use a simpler ready list data structure for ACO.

Dr. Shobaki suggested a code review to try and figure out the issues I have been having debugging these changes.

I have noticed that the spill costs are roughly the same compared to the master branch, but the schedule lengths are longer. I have noticed this most easily on a specific region in cactus (_ZL24ML_BSSN_constraints_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd:436) where pass two often starts with a schedule around length ~12,500. In pass 2, master branch will quickly find a schedule around length 10,000, whereas this branch does not find a schedule below length 12,000.

My two thoughts as to possible leads are that there could be an error in how this new ready list is used, causing it to select instructions in a worse manner than before. There also could be an error in how the heuristics are calculated, leading to poor schedule quality.

Here are the heuristics I am using in sched.ini:

HEURISTIC LLVM

ENUM_HEURISTIC LUC_LLVM

SECOND_PASS_ENUM_HEURISTIC LUC_CP_NID

I also want to mention that I have noticed one bug with the LLVM Heuristic that I have fixed. On line 63 of ready_list.cpp, the line MaxNID = MaxKVs[LSH_NID]; should be MaxNID = MaxNID = DDG->GetInstCnt() - 1;, since the former only sets MaxNID for if the NID Heuristic is used, but not if LLVM is used without NID. I do not have permission to push changes to this repository, so I cannot fix this bug on this branch.

Another observation from using that same region in Cactus, while printing the schedule that is passed into the beginning of pass two, both branches give a schedule that has the instructions in the same order, but the cycles they are scheduled on are different across the two branches.
I did not realize that instruction numbers are not guaranteed to be consistent between passes, so these are probably not the same instructions in the same order

Example:

Cycle# 1 : 0
Cycle# 7 : 1
Cycle# 8 : 2
Cycle# 14 : 3 
Cycle# 19 : 4 
Cycle# 20 : 5 
Cycle# 26 : 6 
Cycle# 31 : 7 
Cycle# 32 : 8

vs.

Cycle# 1 : 0
Cycle# 7 : 1
Cycle# 8 : 2
Cycle# 14 : 3 
Cycle# 19 : 4 
Cycle# 20 : 5 
Cycle# 26 : 6 
Cycle# 27 : 7 
Cycle# 28 : 8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants