1440554 - Add mechanism to CacheIR to elide duplicate guards

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Ted Campbell [:tcampbell]]

Right now we need to be careful about how we generate ICs to avoid generating duplicate shape and group guards. The trouble is use this guards for a variety of invariants and we can't separate concerns if all the logic must coordinate to insert a guard exactly once.

Instead I'd propose some simple tracking in CacheIR (can we do on the operandId? or key'd in the writer?) to detect if a shape/group/proto guard was already emitted for the same operand (without it being clobbered). This would allow us to call guardGroup multiple times with only one emitted and separate logic for type barriers, unboxed layouts, uncacheable prototypes, etc.

Comment 1

[Jan de Mooij [:jandem]]

Do you have an example of something that's much simpler this way (or I can wait for the patch)? I'm a bit worried about complicating the system and how this interact with the pattern matching we currently do in the inspector.

Comment 2

[Ted Campbell [:tcampbell]]

The motivating example for me is SetPropIRGenerator::tryAttachAddSlotStub. In this we need a group guard for:

> - guardGroupForTypeBarrier for the following TypeUpdate IC
> if (Unboxed)
>   - guardGroupForLayout (as determined by TestMatchingReceiver)
> else
>   - if (Uncacheable and need proto)
>     - guardGroupForProto (as determined by GeneratePrototypeGuards)

Right now we duplicate the code of TestMatchingReceiver and have a rewrite of GeneratePrototypeGuards (which introduced a 
correctness bug). I would prefer to write:

> GuardGroupForTypeBarrier
> TestMatchingReceiver
> GeneratePrototypeGuards

And then we are able to change any one of those in the future without onerous review of every IC.