Created attachment 258195 [details] Patch

Comment on attachment 258195 [details] Patch Do we really need the added complexity of architecture-dependent register usage? I think we should keep the LLInt as is, and make sure that we always have regCS1 == tagTypeNumber and regCS2 == tagMask.

(In reply to comment #2) > Comment on attachment 258195 [details] > Patch > > Do we really need the added complexity of architecture-dependent register > usage? I think we should keep the LLInt as is, and make sure that we always > have regCS1 == tagTypeNumber and regCS2 == tagMask. The thinking is uniformity. The LLInt needs to restore all callee saves and therefore needs names for all callee saves. Right now the 64 bit LLint code only know about 3 callee saves, but it needs to restore all callee saves as part of catching an exception. Callee saves are stored in memory in register ID order from low to high addresses. The new regCSN and csrN alias follow the register ID. This simplifies coding the store and load order, especially in the LLInt. If regCS1 and regCS2 where kept as the tag value registers and the highest two register ID callee saves, we'd end up with something like the following (X86-64 example): csr0 / regCS0 rbx csr1 / regCS1 r14 csr2 / regCS2 r15 csr3 / regCS3 r12 csr4 / regCS4 r13 The store order in memory though would be regCS0, regCS3, regCS4, regCS1, regCS2. This would have to be explicitly coded in the LLInt. If we adopt what the patch suggests, for nonFTL tiers regCSN+1 is always stored at a higher address than regCSN, making coding much clearer. The other result is that csrN is the same as regCSN for all platforms.

(In reply to comment #3) > (In reply to comment #2) > > Comment on attachment 258195 [details] > > Patch > > > > Do we really need the added complexity of architecture-dependent register > > usage? I think we should keep the LLInt as is, and make sure that we always > > have regCS1 == tagTypeNumber and regCS2 == tagMask. > > The thinking is uniformity. The LLInt needs to restore all callee saves and > therefore needs names for all callee saves. Right now the 64 bit LLint code > only know about 3 callee saves, but it needs to restore all callee saves as > part of catching an exception. > > Callee saves are stored in memory in register ID order from low to high > addresses. The new regCSN and csrN alias follow the register ID. This > simplifies coding the store and load order, especially in the LLInt. If > regCS1 and regCS2 where kept as the tag value registers and the highest two > register ID callee saves, we'd end up with something like the following > (X86-64 example): > > csr0 / regCS0 rbx > csr1 / regCS1 r14 > csr2 / regCS2 r15 > csr3 / regCS3 r12 > csr4 / regCS4 r13 > > The store order in memory though would be regCS0, regCS3, regCS4, regCS1, > regCS2. > > This would have to be explicitly coded in the LLInt. If we adopt what the > patch suggests, for nonFTL tiers regCSN+1 is always stored at a higher > address than regCSN, making coding much clearer. > > The other result is that csrN is the same as regCSN for all platforms. I see, that makes sense. r=me.

Committed r187877: <http://trac.webkit.org/changeset/187877>

*** This bug has been marked as a duplicate of bug 148658 ***

Comment on attachment 258195 [details] Patch Cleared review? from attachment 258195 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).