[Bug target/54232] New: For x86 PIC code, ebx should be spillable

[Bug target/54232] New: For x86 PIC code, ebx should be spillable

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

             Bug #: 54232
           Summary: For x86 PIC code, ebx should be spillable
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bugdal@aerifal.cx


When generating x86 position-independent code, GCC permanently reserves EBX as
the GOT register. Even in functions that make no use of global data, EBX cannot
be used as a general-purpose register. This both slows down code that's under
register pressure and forces inline asm that needs an argument in EBX (e.g.
syscalls) to use ugly temp register shuffling to make gcc happy.

My proposal, and I understand this may be difficult but I still think it's
worth stating, is that the GOT register EBX should be considered spillable like
any other register. In particular, the following consequences should result:

- If a function is not using the GOT (not accessing global or file-local static
symbols or making non-hidden function calls), all GP registers can be used just
like in non-PIC code. A pure function with no

- If a function is only using a "GOT register" for PC-relative data access, it
should not go to the trouble of actually adjusting the PC obtained to point to
the GOT. Instead it should generate addressing relative to the PC address that
gets loaded into the register.

- In a function that's not making calls through the PLT (i.e. a leaf function
or a function that only calls hidden/protected functions), the "GOT register"
need not be EBX. Any register could be used, and in fact in some trivial
functions, using a call-clobbered register would avoid having to save/restore
EBX on the stack.

- In any function where EBX or any other register is being used to store the
GOT address, it should be spillable (either pushed to stack, or simply
discarded and reloaded with the standard load sequence when it's needed again
later) just like a register caching any other data, so that under register
pressure or inline asm constraints, the register becomes temporarily available
for another use.

It seems like all of these very positive consequences would fall out of just
treating GOT and GOT-relative addressing as address expressions based on the
GOT address, which could be cached in registers just like any other expression,
instead of hard-coding the GOT register as a special reserved register. The
only remaining special-case/hard-coding would be treating the need for EBX to
contain the GOT address when making calls through the PLT as an extra
constraint of the function call ABI.

[Bug target/54232] For x86 PIC code, ebx should be spillable

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-08-12 04:57:07 UTC ---
By the way, the code that inspired this report is crypt_blowfish.c and the
corresponding asm by Solar Designer. We've been experimenting with performance
characteristics while integrating it into musl libc, and I found that the C
code is just as fast as the hand-optimized asm on the machine I was testing it
on when using static libraries without -fPIC, but takes over 30% more runtime
when built with -fPIC due to running out of registers.

[Bug target/54232] For x86 PIC code, ebx should be spillable

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-08-13
            Version|unknown                     |4.8.0
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-13 08:57:15 UTC ---
I think the GOT is introduced too late to do any fancy ananlysis on whether
we need it or not.  I also think that for outgoing function calls the ABI
relies on a properly setup GOT, even for those that bind locally and thus
do not go through the PLT.

[Bug target/54232] For x86 PIC code, ebx should be spillable

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2012-08-13 13:59:17 UTC ---
> I think the GOT is introduced too late to do any fancy ananlysis
> on whether we need it or not.

This may be true, but if so, it's a highly suboptimal design that's hurting
performance badly. 30% on the cryptographic code I looked at, and from working
on FFmpeg in the past, I remember quite a few cases where PIC was hurting
performance by significant measurable amounts like that too. If there's any way
the changes I describe could be targeted even just in the long term, I think it
would make a big difference for a lot of software.

> I also think that for outgoing function calls the ABI
> relies on a properly setup GOT, even for those that bind
> locally and thus do not go through the PLT.

The extern function call ABI on x86 does not allow the caller to depend on EBX
containing the GOT address. This is because the callee has no way of knowing
whether it was called by the same DSO it resides in. If not, the GOT address
will be invalid for it.

For static functions whose addresses never leak out of the translation unit
they're defined in, the calling convention is up to GCC. Ideally it would
assume the GOT register is already loaded in such functions (as long as all the
callees use the GOT), but in reality it rarely does. This is a separate code
generation QoI implementation that should perhaps be addressed as its own bug.

[Bug target/54232] For x86 PIC code, ebx should be spillable

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
.
>From gcc-bugs-return-466039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 10:49:45 2014
Return-Path: <gcc-bugs-return-466039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7605 invoked by alias); 8 Nov 2014 10:49:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7542 invoked by uid 48); 8 Nov 2014 10:49:42 -0000
From: "gnu-org at bignm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63776] [C++11] Regex collate matching not working
Date: Sat, 08 Nov 2014 10:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gnu-org at bignm dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63776-4-jxksI4CKe3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63776-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63776-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00511.txt.bz2
Content-length: 1047

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc776

--- Comment #2 from Tom Straub <gnu-org at bignm dot com> ---
Hi Tim,

Okay, a program very similar to this using the Boost REGEX library and ICU 4.55
works just fine with this.

According to my understanding, the "char" data type and "std::string" classes
were specifically set up in C++11 to handle UTF-8 sequences.

The "sequence of bytes" are actually valid UNICODE characters. So, there should
be no problem, that is, if the std::regex_constants::collate flag is actually
working, since the application is using <locale> and setting the std::locale to
"pt_BR.UTF-8" (which is supported on my box).

It is acting as if it is still in POSIX or C locale, since it doesn't recognize
the accented characters as "[:alpha:]" class.

Here is my G++ version:

$ g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Tom