[PATCH] D14044: Support for 32-bit mingw-w64 in compiler-rt

Mon Oct 26 11:05:37 PDT 2015

vadimcn added a comment.

In http://reviews.llvm.org/D14044#275303, @rnk wrote:

> Here's how I understand the various functions:
>
> - `__chkstk` from msvcrt: takes size in RAX, probes all pages, returns preserving all registers.
> - `__chkstk_ms` from mingw: copies `__chkstk` from msvcrt
> - `_alloca` / `__chkstk` from mingw: helpers for implementing C `alloca()` with custom conventions. They trash volatile registers (ECX/RCX), update the SP, and return a new object address in RAX.

I think they trash RAX/EAX as well.  That EAX contains a pointer to the allocated space on return is just an accident.  I took care to preserve EAX because comments in LLVM's `emitStackProbeCall` say so; not sure if this is used anywhere in LLVM.

> I'd rather simplify LLVM's X86FrameLowering to always use `__chkstk` / `__chkstk_ms` than add support for `__alloca` and Mingw `__chkstk`. It reduces the amount of assembly in compiler-rt, and simplifies LLVM in one step. The downside is that the compiler generates more code around dynamic allocas, which really doesn't matter.

> 

> What do you think?

I personally would be fine with this.
However, the description of builtins module on the compiler-rt page <http://compiler-rt.llvm.org/> says: "//builtins provides full support for the libgcc interfaces on supported targets//".   If compiler-rt is a drop-in for for libgcc, it should provide all functions that libgcc does. If this is not the case, then linking a binary from a mix of LLVM and GCC objects would require linking both to libgcc and to compiler-rt, which, as I've mentioned above, creates a problem with duplicate symbols.
To resolve this in a principled way, we'd probably need to rename all compiler-rt exports. LLVM would also need a new switch to allow targeting either runtime.  A new set of triples for "-llvm" environment?  This is a bigger can of worms than I'd like to open. :-)

Repository:
  rL LLVM

http://reviews.llvm.org/D14044