[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