Created attachment 564251[details][diff][review]
[0004] Add type-set Type policy to optimize based on type inference.
This patch may likely be put inside another bug on which many instruction may depends on. In the mean time I add it here because it is used by patch 6.

(In reply to David Anderson [:dvander] from comment #7)
> Comment on attachment 564246[details][diff][review] [diff] [details] [review]
> Make JSObject private fields visible inside the CodeGeneratorX86Shared.
>
> Review of attachment 564246[details][diff][review] [diff] [details] [review]:
> -----------------------------------------------------------------
>
> ::: js/src/jsobj.h
> @@ +1133,4 @@
> > private:
> > friend struct JSFunction;
> > friend class js::mjit::Compiler;
> > + friend class js::ion::CodeGeneratorX86Shared;
>
> Will this break on ARM? Would it work to have CodeGeneratorShared as a
> friend instead?
At least with gcc this does not seems to cause any problem when we have both forward declarations of CodeGeneratorX86 and CodeGeneratorX64 and when both are declared as friend.
I guess this should not cause any problem because the "friend" keyword is used by the compiler to inform that a named class has the right to access the private member of the current class.
Unfortunately friendship is not inherited in C++. Thus adding CodeGeneratorShared as friend would not factor this. I had to add both CodeGeneratorX86 and CodeGeneratorX64 when I added the implementation for x86 and x64.
I was looking to factor this with macros, but the current implementation would be larger with macros than it is in plain text.
> Another option is to expose static offsetOf accessors.
I didn't check how many times we would need to implement such offsetOf functions to make JSObject properties visible inside code generators. I will advocate that doing so is safe as long as the CodeGenerators do not aggregate or manipulate JSObject values.

Looking at BytecodeEmitter.cpp and JM+TI, it seems like JSOP_INITELEM always has a constant, numeric index. I think we discussed this a bit IRL, but hadn't come to a conclusion yet. Given that, I think the ideal thing here is to choose two ways to compile INITELEM, and to make this decision in IonBuilder:
(1) If the TypeOracle tells us we can't specialize the array, we can just abort for now.
(In the future, we'll want this to become a slow-path, but let's keep it simple to
start.)
(2) If the TypeOracle tells us we *can* specialize the array, emit a series of MIR ops:
v0 = MLoadSlots(array)
v1 = MStoreElement(v0, index, value)
-- MUpdateLength(array)
StoreElement can be modeled off Jan's work for StoreSlot in bug 700303.
UpdateLength is needed if TI is enabled - this decision should be hidden behind the Oracle, though.
I think this simplifies things while providing us with a bunch of reusable components - for example, UpdateLength can be used for array.push and StoreElement for SETELEM.