Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test our implementations against libgcc #65

Closed
japaric opened this issue Sep 14, 2016 · 1 comment · Fixed by #67
Closed

Test our implementations against libgcc #65

japaric opened this issue Sep 14, 2016 · 1 comment · Fixed by #67

Comments

@japaric
Copy link
Member

japaric commented Sep 14, 2016

No description provided.

japaric pushed a commit that referenced this issue Sep 16, 2016
if it exposes the same intrinsics that we implement -- gcc_s doesn't
implement all the intrinsics for all the architectures.

closes #65
@japaric
Copy link
Member Author

japaric commented Sep 18, 2016

This won't work on msvc because there is no libgcc_s.so there. Instead we can link to msvcrt.lib, which contains the intrinsics we want to test against. However, the intrinsics in msvcrt.lib are named differently from the ones in gcc_s/compiler-rt. This is good because we can statically link against that library without worrying about name collisions but it's also annoying because we must now translate from msvcrt naming to compiler-rt naming.

@retep998 has provided us with a list of the intrinsics available in msvcrt.lib. But we still need to translate the names from msvcrt to compiler-rt. That can be done by looking into llvm source code. For example there are code sections like:

// lib/Target/X86/X86ISelLowering.cpp

  if (Subtarget.isTargetKnownWindowsMSVC()) {
    // Setup Windows compiler runtime calls.
    setLibcallName(RTLIB::SDIV_I64, "_alldiv");
    setLibcallName(RTLIB::UDIV_I64, "_aulldiv");
    setLibcallName(RTLIB::SREM_I64, "_allrem");
    setLibcallName(RTLIB::UREM_I64, "_aullrem");
    setLibcallName(RTLIB::MUL_I64, "_allmul");
    setLibcallCallingConv(RTLIB::SDIV_I64, CallingConv::X86_StdCall);
    setLibcallCallingConv(RTLIB::UDIV_I64, CallingConv::X86_StdCall);
    setLibcallCallingConv(RTLIB::SREM_I64, CallingConv::X86_StdCall);
    setLibcallCallingConv(RTLIB::UREM_I64, CallingConv::X86_StdCall);
    setLibcallCallingConv(RTLIB::MUL_I64, CallingConv::X86_StdCall);
  }

that contain the msvcrt names. And other sections like this one:

// lib/Target/ARM/ARMISelLowering.cpp

    } LibraryCalls[] = {
      // ...

      // Integer division functions
      // RTABI chapter 4.3.1
      { RTLIB::SDIV_I8,  "__aeabi_idiv",     CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::SDIV_I16, "__aeabi_idiv",     CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::SDIV_I32, "__aeabi_idiv",     CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::SDIV_I64, "__aeabi_ldivmod",  CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::UDIV_I8,  "__aeabi_uidiv",    CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::UDIV_I16, "__aeabi_uidiv",    CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::UDIV_I32, "__aeabi_uidiv",    CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
      { RTLIB::UDIV_I64, "__aeabi_uldivmod", CallingConv::ARM_AAPCS, ISD::SETCC_INVALID },
    };

that contain the compiler-rt names. Using that information you can conclude that RTLIB::UDIV_I64 === __aeabi_uldivmod === _allmul.

With that background information, here are the next steps:

  • Create a msvcrt crate that links to msvcrt.lib and binds to the msvcrt intrinsics. That crate must expose the same API as the gcc_s crate. Basically, it must provide functions like __muldi3: fn() -> Option<extern unsafe fn(u64, u64) -> u64>. The crate must handle the differences in naming and signature of intrinsics between msvcrt and compiler-rt.
  • Then, probably, we only need to add a #[cfg(target_env = "msvc")] extern crate msvcrt as gcc_s to the root of the rustc-builtins crate (for tests only).

japaric pushed a commit that referenced this issue Sep 22, 2016
test our implementations against gcc_s

if it exposes the same intrinsics that we implement -- gcc_s doesn't
implement all the intrinsics for all the architectures.

closes #65

r? @Amanieu
Tested on Linux x86_64 and against the x86_64 and the arm-gnueabi targets. Unclear whether this works on osx or windows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant