Bug 204726

Created attachment 384577 [details] Patch

Comment on attachment 384577 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=384577&action=review r=me with ChangeLog fix. > Source/JavaScriptCore/ChangeLog:10 > + When we generate ByIdInlineCache and ByValInlineCache, `base` is always > + a cell. Given that, we don't need to store `baseTag` on 32-bits > + version. This patch is removing StructureStubInfo::patch.baseTagGPR. Please fix the alignment. These lines appear to be off by one (they have 1 extra space). Please add a comment here that the code also doesn't make use of the patch.baseTagGPR. It's being passed around, and the register is allocated, but no instructions are being emitted that uses it.

(In reply to Mark Lam from comment #2) > Comment on attachment 384577 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=384577&action=review > > r=me with ChangeLog fix. > > > Source/JavaScriptCore/ChangeLog:10 > > + When we generate ByIdInlineCache and ByValInlineCache, `base` is always > > + a cell. Given that, we don't need to store `baseTag` on 32-bits > > + version. This patch is removing StructureStubInfo::patch.baseTagGPR. > > Please fix the alignment. These lines appear to be off by one (they have 1 > extra space). > > Please add a comment here that the code also doesn't make use of the > patch.baseTagGPR. It's being passed around, and the register is allocated, > but no instructions are being emitted that uses it. Thank you very much for the review. I was thinking in the following case that needs to be checked before upstreaming this patch: We allocate baseTagGPR (it can happen on DFG) but we don't lock this into IC. If we allocate a scratch GPR to this same register, we will clobber baseTagGPR and it can cause issues if we take a slow path that is expecting an EncondedJSValue.

Created attachment 384752 [details] Patch

(In reply to Caio Lima from comment #4) > Created attachment 384752 [details] > Patch Checking if EWS is happy about that.

Comment on attachment 384752 [details] Patch Tested internally and found some issues.

(In reply to Caio Lima from comment #3) > > Thank you very much for the review. I was thinking in the following case > that needs to be checked before upstreaming this patch: We allocate > baseTagGPR (it can happen on DFG) but we don't lock this into IC. If we > allocate a scratch GPR to this same register, we will clobber baseTagGPR and > it can cause issues if we take a slow path that is expecting an > EncondedJSValue. I think I might be able to reproduce such case with a test. I'll upload it and a new version of patch as soon as I have it done..

(In reply to Caio Lima from comment #3) > > Thank you very much for the review. I was thinking in the following case > that needs to be checked before upstreaming this patch: We allocate > baseTagGPR (it can happen on DFG) but we don't lock this into IC. If we > allocate a scratch GPR to this same register, we will clobber baseTagGPR and > it can cause issues if we take a slow path that is expecting an > EncondedJSValue. I'm not confident that it is safe to upstream current patch and this will require deeper investigation. I was investigating the case where we generate IC in the `viaProxy()` on `AccessCase::generateWithGuard()`. The problem in this path is that we remove `baseTagGPR` from `usedRegisters` set and it leaves a breach to have baseTagGPR clobbered when we fallback to slow path. I'll revisit this later when having more time, since it requires more investigation.