[Mono-devel-list] [PATCH] Don't spill return from call

[Ben Maurer]

Maybe it would be easier to just test if the next instruction started a
BB? Because the call pushes something on to the stack, there would be an
item on the stack at the beginning of the next instruction; Thus, it
would not be possible for a backwards branch to reference that
instruction, meaning we would already have the information available.
Until copyprop is implemented s.t. it can catch the problem, this seems
like a good workaround.

Also, what is the bug with CEE_RET?

Tonight I will add a testcase for the conditions you described to the IL
tests, and add a comment to the code.

-- Ben

>>> Paolo Molaro <lupus at ximian.com> 04/26/04 04:47 AM >>>
On 04/23/04 Ben Maurer wrote:
> By having temporary variables like these, we reduce the chances that
> other variables will be put into registers, and increase code size. It
> also increases the complexity of analyzing the code.

When copy propagation is implemented this won't be an issue anyway.

> One thing I was not sure of is why this optimization was commented
out.
> There was no rationale behind the if (0. The code was commented since
> the initial checkin, so i have no idea why it is not enabled.

It's not enabled because it produces incorrect code when the instruction
following the call is the start of a new basic block and because
implementing copy propagation will solve this issue (and many more).
To that, you added your own bug with the handling of CEE_RET.

> I had no failures on the regression tests, nor the jit tests. I also
did
> a bootstrap.

Maybe you should also start writing your own tests to exercize the
changes you make...

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list