A problem with passing the Global Offset Table address to a function in %edx
I am in the process of porting gcc-10.2.0 to a non-Unix operating system called VOS that does have a POSIX Application Programming Interface (API) but does not have a Unix Application Binary Interface (ABI). The main way that VOS differs from Unix is in how the Global Offset Table (GOT) for position-independent code (PIC) is handled. In Unix PIC code, there is one GOT per program and each function is responsible for finding the address of the GOT on its own. In VOS, all non-kernel code is PIC, and there is a different GOT for each thread in a program. Therefore, each function is responsible for passing the address of the GOT in a register. On IA-32, that is %edx, which is a caller-save register. (On PA-RISC, it is r27, which is a callee-save register.) Also on VOS if a function calls a nested function, it needs to pass the static-chain address in %ecx, another caller-save register. Many years ago, when I ported gcc-3.4.6 to VOS, I had no trouble doing this. At the call-site I merely set %edx to the address of the GOT and did a use_reg of %edx, which attached a (use (reg:SI 1 dx)) to the CALL_INSN_FUNCTION_USAGE list hanging off the CALL instruction. A similar thing happened with %edx for nested function calls. However, with the gcc-10.2.0 port this now fails. There are 4 passes that run dead code elimination (DCE), sometimes as a side-effect for what the pass is mostly doing, and those passes eventually decide that the set of %edx is dead code and eliminates it. The reason it happens is that the DCE code (run_fast_df_dce) is run as a side-effect of a live-register problem and is considered a recursive call. This causes DCE to ignore the register uses in the CALL_INSN_FUNCTION_USAGE list and, thus the prior set becomes dead. I believe this happened because our port of gcc-3.4.6 to VOS was not accepted as a contribution to the core product, athough we did offer it, and the only other port that had a similar ABI was to IA-64, which I believe is no longer supported. I enclose some -da output from a compilation of a hello_world main function that illustrates this problem in the cse1 pass. Any line that starts with "**" is a result of debugging code that I have inserted to help me figure this out. Thanks, Richard Barnes hello_world.c.242r.cse1 Description: hello_world.c.242r.cse1
64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32
We are porting gcc-10.2.0 to a proprietary OS called VOS with a POSIX API that
runs on x86-32. We are using a prior port of gcc-3.4.6 to build the port
natively. When the build gets to the point where it compiles libgcc2.c with the
gcc-10.2.0 compiler, it goes into an infinite loop and eventually runs out of
virtual memory. We analyzed the failure by building libgcc2.c with -da and
found that the build fails while compiling __mulvsi3.c. This build fails
whether our build is using the reload pass or the LRA pass to run after the IRA
pass.
What is contributing to the problem is that we must compile libgcc2.c with
-fpic because the VOS runtime is position-independent with a different GOT for
each thread, that the VOS ABI requires that when a function is entered, %edx
must contain the GOTP, and that %edx must contain the GOTP at each call point,
all of which is very different than the Unix ABI. Furthermore, GNU code
requires that %ebx contain the GOTP wherever @PLT or @GOT relocation is used,.
Since %edx also contains the upper half of the result of the multiply that adds
to the register pressure.
I am attaching mulvsi3.c, which exhibits the problem.
During the failed builds, it looks like spilling keeps failing while trying to
color or coalesce pseudo registers. I have built my own Chaitin register
allocator that we use with our native compilers, and I know that we do not
color the registers until no constrained registers are left after pruning the
interference graph. If pruning fails to eliminate constrained registers, we
spill and rebuild the interference graph and try again. While spilling does
take time, this should not take too many passes to work. The behavior that the
reload and LRA passes exhibits concerns me because that violates this rule.
Also, I note that comments in the assign_by_spills() function show that the
author was concerned about the possibility of multi-register reload-pseudos
when the hard regs pool is fragmented. Something that could easily happen on
x86-32.
I would appreciate any advice that would help us deal with this problem.
Thanks,
Richard Barnes
Stratus Technologies
extern void abort (void) __attribute__ ((noreturn));
typedef int SItype __attribute__ ((mode (SI)));
typedef int DItype __attribute__ ((mode (DI)));
SItype
__mulvsi3 (SItype a, SItype b)
{
const DItype w = (DItype) a * (DItype) b;
if ((SItype) (w >> 32) != (SItype) (w) >> 31)
abort ();
return w;
}
Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32
Unfortunately, our OS is only a 32-bit OS. It's ABI is only a 32-bit ABI. As you imply, if we had a 64-bit OS, we would have more registers and more memory and would probably avoid this problem. Also, libgcc2.c is supposed to be built natively by the gcc-10.2.0 compiler you have just created. Richard Barnes Stratus Technologies From: H.J. Lu Sent: Friday, May 28, 2021 3:34 PM To: Barnes, Richard Cc: gcc@gcc.gnu.org Subject: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32 [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] On Fri, May 28, 2021 at 12:10 PM Barnes, Richard wrote: > > We are porting gcc-10.2.0 to a proprietary OS called VOS with a POSIX API > that runs on x86-32. We are using a prior port of gcc-3.4.6 to build the port > natively. When the build gets to the point where it compiles libgcc2.c with > the gcc-10.2.0 compiler, it goes into an infinite loop and eventually runs > out of virtual memory. We analyzed the failure by building libgcc2.c with -da > and found that the build fails while compiling __mulvsi3.c. This build fails > whether our build is using the reload pass or the LRA pass to run after the > IRA pass. I have no comment on your issue. I am just curious why you don't build your 32-bit x86 OS with x86-64. > What is contributing to the problem is that we must compile libgcc2.c with > -fpic because the VOS runtime is position-independent with a different GOT > for each thread, that the VOS ABI requires that when a function is entered, > %edx must contain the GOTP, and that %edx must contain the GOTP at each call > point, all of which is very different than the Unix ABI. Furthermore, GNU > code requires that %ebx contain the GOTP wherever @PLT or @GOT relocation is > used,. Since %edx also contains the upper half of the result of the multiply > that adds to the register pressure. > > I am attaching mulvsi3.c, which exhibits the problem. > > During the failed builds, it looks like spilling keeps failing while trying > to color or coalesce pseudo registers. I have built my own Chaitin register > allocator that we use with our native compilers, and I know that we do not > color the registers until no constrained registers are left after pruning the > interference graph. If pruning fails to eliminate constrained registers, we > spill and rebuild the interference graph and try again. While spilling does > take time, this should not take too many passes to work. The behavior that > the reload and LRA passes exhibits concerns me because that violates this > rule. Also, I note that comments in the assign_by_spills() function show that > the author was concerned about the possibility of multi-register > reload-pseudos when the hard regs pool is fragmented. Something that could > easily happen on x86-32. > > I would appreciate any advice that would help us deal with this problem. > > Thanks, > Richard Barnes > > Stratus Technologies > -- H.J.
Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32
Our OS is not built with gcc. It is built with native compilers and linkers. It sounds like you are talking about cross compiling, which is something we have considered but hope to avoid. Richard Barnes From: H.J. Lu Sent: Friday, May 28, 2021 3:52 PM To: Barnes, Richard Cc: gcc@gcc.gnu.org Subject: Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32 [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] On Fri, May 28, 2021 at 12:42 PM Barnes, Richard wrote: > > Unfortunately, our OS is only a 32-bit OS. It's ABI is only a 32-bit ABI. As > you imply, if we had a 64-bit OS, we would have more registers and more > memory and would probably avoid this problem. Also, libgcc2.c is supposed to > be built natively by the gcc-10.2.0 compiler you have just created. > Are you aware that you can build a 32-bit OS with x86-64? You can try -mx32 with GCC on Ubuntu. You will get more registers as well as IP relative addressing. -- H.J.
Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32
I found the problem, and it was a mistake I made elsewhere that resulted in %edx being busy everywhere. I have fixed it and consider the issue resolved. Richard Barnes From: Barnes, Richard Sent: Friday, May 28, 2021 3:59 PM To: H.J. Lu Cc: gcc@gcc.gnu.org Subject: Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32 Our OS is not built with gcc. It is built with native compilers and linkers. It sounds like you are talking about cross compiling, which is something we have considered but hope to avoid. Richard Barnes From: H.J. Lu Sent: Friday, May 28, 2021 3:52 PM To: Barnes, Richard Cc: gcc@gcc.gnu.org Subject: Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32 [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] On Fri, May 28, 2021 at 12:42 PM Barnes, Richard wrote: > > Unfortunately, our OS is only a 32-bit OS. It's ABI is only a 32-bit ABI. As > you imply, if we had a 64-bit OS, we would have more registers and more > memory and would probably avoid this problem. Also, libgcc2.c is supposed to > be built natively by the gcc-10.2.0 compiler you have just created. > Are you aware that you can build a 32-bit OS with x86-64? You can try -mx32 with GCC on Ubuntu. You will get more registers as well as IP relative addressing. -- H.J.
