875225 - IonMonkey: Remove failing boundschecks on GWT linpack benchmark

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Hannes Verschore [:h4writer]]

We are bailing on :428 due to boundschecks. This sounds bogus. Haven't found yet why we are failing them, investigating now. Removing the bailouts would increase our performance from 2.03s to 1.82s

Comment 1

[Hannes Verschore [:h4writer]]

Not sure what the solution is. I will have to discuss it with other people.
So this is a small testcase showing the behaviour in linpack GWT. This will bail every time create_array gets called:

function create_array(length){
  var array = new Array(length);             (1)
  for (var i = 0; i < length; ++i) {
    array[i] = 0;                            (2)
  }
  return array;
}
function test() {
  for (var i = 0; i < 10; i++) {
   var arr = create_array(1001);
   var a = ["&"];
   arr[a[1]] = 1;                            (3)
  }
}
test();


1)
array->resultTypeSet() =>  object[1] [0xb5830be0]
[0xb5830be0] : <0xb583d010> unknown {} 

2)
As a result of that array typeset:
types->unknownProperties() == true
types->hasObjectFlags(cx, types::OBJECT_FLAG_LENGTH_OVERFLOW) == true
ElementAccessHasExtraIndexedProperty == true
writeOutOfBounds == false

so we use MStoreElement instead of MStoreElementHole
(this last one wouldn't bail, since it supports adding to array)

3) 
Here we do a JSOP_SETELEM with a string as index. MonitorAssign get's called and MarkTypeObjectUnknownProperties(cx, obj->type()); So that's the reason we have no type information or unknownProperties. I don't know what the reason is for this and hg annotate and following bugs didn't show me good information ...

So I'm a bit in the dark what we want to change? Do we want to adjust (2) and use MStoreElementHole for unknownProperties? Or is the optimization in 3 maybe not needed anymore?