Hi Craig

every time we had someone in a VM course play around with Squeak bytecode these "digrams" (or sometimes even trigrams, when a returnTop is involved) where
the first obvious go-to "optimizables".

The point is, these combinations are typically the result of adjacent AST nodes being encoded without the knowledge that they operate on the same temp.
One node ends with the popIntoTemp, the next one starts with a pushTemp.

It is a typical compiler optimization to elide those things, but you typically need multiple passes, SSA transformations or other shenanigans to propagate all necessary information.

True, cogit could fuse those, sista could fuse those, or even the basic compiler could fuse those, but it such optimization passes always come at the cost of increased complexity.

Best regards
	-Tobias




> On 6. Jun 2022, at 04:31, Craig Latta <craig at blackpagedigital.com> wrote:
> 
> 
> Hi--
> 
>     Apologies if this is obvious, or I misunderstood. I notice many compiled methods with storePop instructions followed by push instructions for the same location. E.g., in the Sista version of Parser>>method:context:
> 
> 305 <D7> popIntoTemp: 7
> 306 <47> pushTemp: 7
> 
>     Aren't those two instructions the same as a single storeTemp instruction? Even if that optimization were made, would it result in the same machine code from cogit anyway, and is that why the optimization isn't made at the Smalltalk compiler level? If so, where in cogit can I find the optimization? Wouldn't there be less work for cogit to do if it could expect this optimization from the Smalltalk compiler?
> 
>     If cogit doesn't make this optimization, would system performance improve if the Smalltalk compiler did it? I see that well over 10% of the methods in the upcoming release would be affected. Is there some reason why doing this optimization isn't a good idea? I'm writing a new Smalltalk compiler (based on a more straightforward parser) and I'd like to try this optimization.
> 
> 
>     thanks!
> 
> -C