-
Notifications
You must be signed in to change notification settings - Fork 0
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
Peephole Optimizer Format #13
Comments
At a basic level, it's not really about assigning a variable, but if branching or even checking is useless. Our previous optimizer had a decent amount of patterns that had to navigate to labels. Off the top of my head, an example pattern could be something like:
to
|
And you were able to fully traverse to other labels? I don't see a really elegant way of doing that without making everything mutable. If we do allow access and modification for branches, then I don't see how we'll combine all the effect at the end |
Yes we were able to fully traverse. |
There's no point using haskell at that point then. We might have the option to make apis such as
|
The benefit of something like that is we don't need to use recursion either, so the problem won't blow up exponentially. But it's probably still less efficient |
I'd probably just expose a similar interface to https://github.com/comp520/Peephole-Template/blob/master/JOOSA-src/optimize.c We can ignore the Functions
|
I thought about this a while back but didn't have time to write about it until now.
For peephole, I think the easiest way is to just expose the instruction list as is, and offer some helper functions (things like if a label is used). We won't allow navigation to other labels, which will also avoid the cycle problem. I'm not sure how much benefit will come from navigation anyways; it's mainly if branching is useless, ie from assigning the same thing to a var regardless of the path. At that point it isn't really peephole
The text was updated successfully, but these errors were encountered: