[Webkit-unassigned] [Bug 71498] New: JIT-specific code should be able to refer to register types even on JIT-disabled builds
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Nov 3 13:04:52 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=71498
Summary: JIT-specific code should be able to refer to register
types even on JIT-disabled builds
Product: WebKit
Version: 528+ (Nightly build)
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: P2
Component: JavaScriptCore
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: fpizlo at apple.com
Increasingly, code in CodeBlock and elsewhere outside of the JIT refers to JIT features. This is part of the evolution of the system to rely more on high-performance JIT optimizations. But we still want to support no-JIT builds. Doing this often means that we must insert #if's in a bunch of places if no JIT support is present. A particularly egregious case is the current build bug introduced by http://trac.webkit.org/changeset/99148. That changeset makes use of MacroAssembler::RegisterID in structs and classes that are placed in CodeBlock. In the case that the JIT is turned off, no instances of those classes are ever instantiated. But we've taken the approach of letting them be declared without #if guards to minimize noise.
But this breaks because the latest addition to these classes is ValueRecovery (referenced from InlineCallFrame, which is referenced from CodeBlock's RareData), which uses MacroAssembler::RegisterID. We can either fix this by adding #if's around all references from CodeBlock to ValueRecovery (transitively, of course), or we can localize the noise by making MacroAssembler.h define a dummy MacroAssembler, with a dummy RegisterID, even if the assembler (and the JIT) is disabled. This will have no run-time overhead, since this would just be an empty class with some typedef's, and ValueRecovery is never instantiated in non-JIT builds anyway.
--
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