[webkit-dev] Load elimination

[Peter Siket]

Hi All!

I would like to create a small filter which eliminates unnecessary 
LIR_ld instructions. It seems that there are several unnecessary
loads which can not be simply eliminated by the CSE filter due to its 
elimination is not as simple as the elimination of other CSE
instructions like LIR_add.

For example:
    class C {
        var x : int  = 5;
        var y : int = 7;
    }

    var o : C = new C();

    function f(o) {
        var j = 0;
        for (var i = 0; i < 20; i++) {
            j += o.x + o.y + (o.x + o.y) * (o.x + o.y);
        }
        return j;
    }

   
The values of o.x and o.y are loaded every time when they are used but 
only one of them would be enough.
Since the loads are done by different LIR instructions the add 
instructions will also be executed three times.
If we could eliminate the loads the CSE filter would eliminate the 
second and third adds too.

In the first implementation of the filter I check only the LIR_ld 
instructions created by the getslotvalue
function of the Interpreter and all the store insertions. Between the 
first and the second loads of o.x all the
possible stores, which can modify the value of o.x should be checked. If 
anything modified the o.x between the two
loads than the second load could not be eliminated.

It passes on almost all of the acceptance tests but fails in 28 cases. 
It seems that not only the store instructions
but some IL primitive functions can also modify the objects so that is 
why it fails in test. If I handled this situation
too conservatively and let the elimination of a load instruction only if 
there were no call instruction between the
first and the second load than there would be almost nothing to eliminate.

I think that it could work if I could decrease the number of possible 
primitive-function calls when the load must not be
eliminated but unfortunately I am not yet familiar with the tamarin in 
detail to see everything.

I would welcome any opinion, observation, comment or anything about this. :)

Thanks,
   Peter Siket