I'm confused- the "generate+clean up junk" problem is real and huge, but whether you use SSA is orthogonal (on its own it doesn't even *represent* moves) you can generate good SSA directly (e.g. https://link.springer.com/content/pdf/10.1007%2F978-3-642-37051-9_6.pdf … instead of llvm-style mem2reg), *or* bad move-y 3AC
Eg., we are saying, do not dump your initial SSA into code. Instead, you want to do a bunch of work to make sure you have an optimal set of things first, and _then_ you start with that code.
-
-
Obviously you can always call something SSA at any time because EVERY POSSIBLE PIECE OF CODE HAS AN SSA FORM. That is not interesting. Anyway, I give up at this point. I thought it should be relatively clear what everyone was talking about but I guess not :(
-
Hm, it seems like we both agree with the paper even if I don't understand your description of it. All I was responding to was the initial claim that "SSA adds in a lot of mov instructions, which are supposed to be optimized away later" because that is not inherent to SSA
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.