Bug 175366 – FTL's compileGetTypedArrayByteOffset needs to do caging

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

I think that for primitive gigacage, it has to do it.  The tricky thing about it is that it needs to handle null vectors.

[Filip Pizlo]

Created attachment 317998 [details]
maybe the patch

[Filip Pizlo]

Created attachment 317999 [details]
the patch

[Saam Barati]

Comment on attachment 317999 [details]
the patch

View in context: https://bugs.webkit.org/attachment.cgi?id=317999&action=review

> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:11653
> +        LBasicBlock lastNext = m_out.insertNewBlocksBefore(notNull);

Why this instead of relying on the result of appendTo below?

[Filip Pizlo]

(In reply to Saam Barati from comment #3)
> Comment on attachment 317999 [details]
> the patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=317999&action=review
> 
> > Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:11653
> > +        LBasicBlock lastNext = m_out.insertNewBlocksBefore(notNull);
> 
> Why this instead of relying on the result of appendTo below?

That way, the code that we insert at the end of the current block will do the right thing if it also contains a control flow diamond.

Using the result of appendTo() is only safe if you are absolutely sure that none of the things you did before newBlock and appendTo added any other blocks.  Therefore, although I used to use the result of appendTo() a lot, I don't think it's actually safe.

[Filip Pizlo]

Landed in https://trac.webkit.org/changeset/220628/webkit

[Radar WebKit Bug Importer]

<rdar://problem/33865694>