-
Notifications
You must be signed in to change notification settings - Fork 8
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
isMAC() fixed #15
isMAC() fixed #15
Conversation
Which fiction fuse mul with add into new muladd? |
Function combineMulAdd(). But it's not used in this mapper in fact. |
Can you please apply that combineMulAdd() on a fir kernel and show the two DFGs (before and after) here? |
Fir kernel doesn't contain a mul and add that can be combined, So I show inttCore kernel (apply combine("mul","sub") before and after) instead. I notice that combineMulAdd() is not as useful as combine("mul","add") or combine("mul","sub") or others, because it only combines Critical dfgNode. Note that (19)mul and (21)sub are combined in InttAfterFuse.png and become (19)mulsub. |
|
|
|
I will check the |
Below is Fir before and after combineMulAdd()(the one I remove judgment of critical nodes). Note that |
|
Nice.
|
So the purpose of combineForIter() is to combine any kind of critical path, no matter it's add/compare/br/phi or add/phi (those two are the most common ones but there exit other critical paths)? In that way, I need to change the logic of combineForIter(). I also want to know if this task is relevant to the mail you sent to us (Help needed ...) before or not. |
Yes, we want to fuse all the nodes within the critical cycle. However, we also want to make it parameterizable, for example, some cases, we may not want to over fuse them. So we can start from the above two cases I guess? Yes, this is related to the mail. Fusion is a critical step towards better mapping. |
OK, I will try to leave a parameter interface in combineForIter() and try to provide some tests for my modifications. |
I made it in a recursive way, sir. But I want to confirm some questions.
|
Cool, great progress. Recursive way is very popular for pattern recognition. I am fine with either recursive or iterative. |
DFG::combineIter() and DFG::combineForIter() is made to fuse the pattern in DFGs regardless the order or size of the pattern. I update the codes and you can merge the PR if there is no question. |
combineForIter() is to accept fusion pattern that user provides and it will call combineIter(). Here is an example of code of fusion pattern "add -cmp-br-phi" and "phi-add".
|
DFG::combineForIter() combine the original two functions and can deal with one string pattern with multiple cycles.
I update combineForIter() and combineIter() into one function and this is an example code of how to use this function. The result DFG is the same as before.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try to click on Resolve conversation
with appropriate comments (e.g., fixed, won't fix).
I use list<string>* instead of string* and initialize t_matchedNodes inside the function.
I update combineForIter() with one parameter and fix the name issue. The result DFG is the same as before.
|
Fixed all your needs
After combineMulAdd(), the opcodeName changes. So isMAC() detects new opcodeName to verify whether it is MAC and isMAC() won't always return true.