[Webkit-unassigned] [Bug 21571] New: VoidPtrPair breaks CTI on Linux

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21571

           Summary: VoidPtrPair breaks CTI on Linux
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: Linux
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: alp at nuanti.com
                CC: mrowe at apple.com, barraclough at apple.com
 BugsThisDependsOn: 20760


VoidPtrPair return in revision r37457 broke CTI on Linux, which I was hoping to
switch on by default (bug #20760, r37457).

The problem is that the convention on Linux is to always use the stack for
struct returns (pcc convention) while gcc on Darwin uses the register for small
structs. The new code assumes the latter.

There are a few possible workarounds:

1) Build with -freg-struct-return. This sounds like quite a large change to
calling conventions but curiously doesn't seem to break any applications or
cause any regressions. If this is viable and is shown to prove performance
elsewhere, we may actually want to turn this on in Linux builds at some point,
but to do that we need to do more research. It would actually be nice to turn
this on since it can generate better code for C++ smart pointers which are used
extensively in WebCore. Not an immediate solution unless anyone can advice
better here.

2) Use a union to vectorise the structure to a uint64_t and return that. This
works, but generates different machine code even when building with
-freg-struct-return so needs to be perf tested in Darwin builds or made
platform-conditional. I have a patch to do this if anyone's interested.

3) ifdef the new code and re-introduce the original code conditionally.

4) Conditionally generate machine code that reads the structure's values
according to the pcc convention.

Any thoughts on which way to go?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.