[Mono-devel-list] [PATCH] Don't spill return from call
05mauben at hawken.edu
Mon Apr 26 07:44:35 EDT 2004
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.
>>> 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
> 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
> a bootstrap.
Maybe you should also start writing your own tests to exercize the
changes you make...
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
More information about the Mono-devel-list