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
