[Vm-dev] Moving simSelf into simStack and eliminating optStatus

[Eliot Miranda]

Hi Clément,

On Tue, Jan 23, 2018 at 12:06 AM, Clément Bera <clement.bera at inria.fr>
wrote:

> It's ok to me.
>
> Hopefully RegAllocatingCogit won't use this anyway.
>
> Btw, I had this idea the other day. In the Scorch back-end, I do liveness
> analysis. So I could generate multiple kinds of pushTemp:, for example:
> pushTempLastUse: => the temp is pushed, but it will never ever be used
> again so no need to write it back if it's a register and the register can
> be destroyed / mutated.
> pushTempLastUseNoDeopt: => the temp is pushed, but it will never be used
> again except if a deoptimisation path is taken. It may need to be written
> back to stack later, but the register can be destroyed or mutated.
> pushTempWillBeUsed: => the temp is pushed and but the temp value will be
> used again, keep the register live.
>

Yes!  I like this a lot.  My first cautionary thought is tat the middle one
will be difficult to use because we always keep the stack ordered.  Bit the
first and the last should be easy to use in the JIT.  Where this is useful
is in the register allocation strategy for loops.  The distinction between
pushTempLastUse: and pushTempWillBeUsed: isn't useful for non-loop code
because register allocation for temporaries occurs when a temporary is
accessed.  But for loops we simply copy back the live register set to the
head of the loop on the first pass.  Using pushTempLastUse: may mean mean
we don't bother to copy back registers that aren't live at the end of the
loop.

Anyway, we need RegisterAllocatingCogit to work and then we can explore
this :-).


>
>
> On Tue, Jan 23, 2018 at 2:47 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> Hi Ronie, Hi Clément, Hi All,
>>
>>     one poor design decision I made when writing
>> StackToRegisterMappingCogit was in keeping simSelf, the simulation stack
>> entry for the receiver, separate from simStack, the simulation stack
>> entries for the stack proper.  I'm now at a point where I want to get
>> RegisterAllocatingCogit working properly so that soon Clément and I can
>> merge it into the SistaCogit and get much improved register allocation for
>> Sista/Scorch.  So I'm starting by duplicating StackToRegisterMappingCogit
>> and making the changes in the city so I can verify that the existing one
>> and the new one without simSelf or optStatus generate exactly the same code.
>>
>> First of all, is that ok with both of you?
>>
>> Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that
>> it is only ever called with nativeIndex being supplied
>> from simNativeStackPtr.  If you agree with me that that is the case would
>> you object to me deleting ssFlushTo:nativeFlushTo: and
>> implementing ssFlushTo: to include LowcodeVM ifTrue: [self
>> ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner,  We can
>> always make it more complicated later on if required, but right now I'd
>> like to keep things as simple as possible.
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>*Villeneuve
> d
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>'Ascq
> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>*
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180124/3c69859d/attachment.html>