Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
irjit: Optimize out more temps and lwl/lwr operations #10516
This moves to using a Load32Left and related op, instead of generating the masking right then and there. It still generates the masking before execution, just as an optimization pass.
The pass will be skipped when using a breakpoint, but then we can just leave the backend to interp fallback. This way we never have to reimplement these in a backend, since they're annoying.
On the way, I optimized out two cases, which happened with lwr but also happened generally. Most specifically, this:
Would previously turn into:
(which is actually two separate optimizations.)
I haven't really tested the changes to the disabled passes though, just tried to keep them right. Don't remember if they work or were just not worth the extra cycles...
For the interpreter, it might actually be faster to leave the LoadLeft etc ops behind when they can't be combined, but we definitely want to combine them when we later emit native code from the IR, to avoid duplicating that work for each backend. Anyway, I'm not suggesting to change anything here, just making a note.
Another thing. The current IR is nice for interpretation but I think if we really want to optimize whole functions with it eventually, we might want to raise it to tree-form, like most other IRs. That avoids all the silliness of having to move ops up and down in order to be able to do peephole optimizations, or various scans in passes - ops will always have their inputs accessible directly in the tree form. But that's for later of course, if at all.
Jan 10, 2018
Yeah, I'm a little worried about such optimizations since we (might) still have to keep filling regs (see: discard jr ra not working everywhere.)
Though, I wonder if we could use the analyst to detect if jal ever reads from those regs. Would have to discard those results if we ever compiled code not analyzed, though.