[Webkit-unassigned] [Bug 68582] DFG JIT does not support to_primitive or strcat
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Sep 22 11:50:46 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=68582
--- Comment #8 from Filip Pizlo <fpizlo at apple.com> 2011-09-22 11:50:46 PST ---
(In reply to comment #7)
> (From update of attachment 108297 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=108297&action=review
>
> > Source/JavaScriptCore/assembler/AbstractMacroAssembler.h:166
> > + // This is only here so that TrustedImmPtr(0) does not confuse the C++
> > + // overload handling rules.
>
> I am a little confused by this. Why is it important to be able to compile conversion from the constant 0 and not the constant 1?
You should never use TrustedImmPtr(1) to assemble an int constant; that's what Imm32() and friends are for.
What happened is that if you only have one overload for TrustedImmPtr(), and it takes void*, then you can safely call TrustedImmPtr(0). But when I added a size_t overload for TrustedImmPtr(), it meant that the compiler would reject the conversion from 0 to void*, and loads of code failed to compile. So I added an int overload, but wanted to have this overload assert that it's not being used to store real int32s.
>
> > Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:1552
> > + // FIXME: add string speculation here.
>
> Should capitalize the "a" in "Add".
Got it!
>
> > Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:1611
> > + for (int operandIdx = 0; operandIdx < (int)node.numChildren(); ++operandIdx) {
>
> Could we use size_t for this type instead of int, or is there a good reason to use int and cast numChildren? Is it just that we don’t want to use a 64-bit index?
Yeah, of course, that would be better. I think actually numChildren() is unsigned, so I should use that. (It's unsigned and not size_t because we try to pack things tightly in DFG::Node, and because if we have a DFG with more than 2 billion nodes in it, we're probably dead already.)
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list