Basic support for builtins from compiler-rt #18734

vchuravy · 2016-09-29T21:30:23Z

Compiler-rt is a support library for clang/llvm. It is used to support llvm intrinsics backend agnostic. Examples are soft-fp support on ARM and Float16 support.
A motivating use-case is #17344, related issues are #14818, #18287 (comment), and this will allow us to properly fix #4905.

Caveats

compiler-rt is often distributed alongside clang as a static library. In order to support JIT compilation we have to convert the static library into a shared object file.
libcompiler-rt.so is not used by anybody, but Julia so this PR currently installs it to usr/lib/julia.
Compiler-rt's build-system is coupled tightly to llvm and we would need to either build CLANG or switch to 3.8.1
This PR to allows to build compiler-rt standalone (currently without support for atomics) following https://github.com/ReservedField/arm-compiler-rt

I am not very experienced in writing Makefiles so I would like to have some critique and I will need some help for non-Linux systems and ARM.

TODO

tkelman · 2016-09-29T21:46:54Z

Make.inc

@@ -228,6 +228,9 @@ LLVM_DEBUG := 0
 #LLVM_USE_CMAKE: defined in deps/llvm-ver.mk as it depends on LLVM_VER_SHORT
 # set to 1 to get clang and compiler-rt
 BUILD_LLVM_CLANG := 0
+# set to 0 to not build compiler-rt standalone.
+# it will still be build if BUILD_LLVM_CLANG is set to 1


will still be built

tkelman · 2016-09-29T21:48:15Z

deps/Makefile

@@ -39,7 +39,7 @@ include $(SRCDIR)/tools/git-external.mk
 # prevent installing libs into usr/lib64 on opensuse
 unexport CONFIG_SITE

-DEP_LIBS :=
+DEP_LIBS := compiler-rt


only ifeq($(BUILD_COMPILER_RT), 1), right?

It is more complicated than that. As far as I can tell we will need to unconditionally build with compiler-rt (except for llvm-free builds).
BUILD_COMPILER_RT==1 means that we will try to build a standalone compiler-rt iff LLVM hasn't build one.

tkelman · 2016-09-29T21:49:30Z

deps/compiler-rt.mk

+##
+# In order to support fallbacks within llvm we need to support
+# compiler-rt. This means linking sys.so against it and resolving
+# symbols at during JIT. For the latter part we need to create


"symbols during JIT" ? or missing word?

tkelman · 2016-09-29T21:50:25Z

deps/compiler-rt.mk

+# There are several configurations to take into account.
+# 1. USE_SYSTEM_LLVM == 1
+#    libclang_rt.builtins is distributed with clang and so
+#    we assume that USE_SYSTEM_LLVM == 1 means that clang is also


not sure this is a safe assumption to make

Yes this adds an implicit dependency on clang...
We could relax this a bit by using a standalone build for USE_SYSTEM_LLVM == 1 && BUILD_COMPILER_RT == 1, but for USE_SYSTEM_LLVM == 1 && BUILD_COMPILER_RT == 0, we need to fall back onto a system version of compiler-rt and that comes at least on Archlinux with clang.

At least for Fedora RPMs, I need USE_SYSTEM_LLVM=1 and I also have to build LLVM with gcc. Is that a problem, or is installing clang enough?

Installing clang will be enough or you can set STANDALONE_COMPILER_RT:=1

tkelman · 2016-09-29T21:51:07Z

deps/compiler-rt.mk

+#    we assume that USE_SYSTEM_LLVM == 1 means that clang is also
+#    installed.
+# 2. BUILD_LLVM_CLANG == 1
+#    libclang_rt.builtins is build with clang and we can pick that up.


is built with

tkelman · 2016-09-29T21:51:40Z

deps/compiler-rt.mk

+# 3. BUILD_COMPILER_RT == 1
+#    Download and install compiler_rt independently of llvm/clang
+#
+# Since we need the shared opjectfile for JIT there is no USE_SYSTEM_COMPILER_RT


is there really no desire from upstream to fix this there?

I can try and fix this upstream.

worth a shot, I'd rather carry patches and maybe adjust the way we build LLVM if the long-term idea is we can upstream the patches, instead of needing extra makefile wrappers here

We will still need the standalone buildscript, but you are right it is worth a shot.

Also, "opjectfile" -> "objectfile"

tkelman · 2016-09-29T21:54:35Z

deps/compiler-rt.mk

+	$(CC) $(LDFLAGS) -shared $(fPIC) -o $@ -nostdlib $(WHOLE_ARCHIVE) -L$(CRT_DIR) -l$(CRT_STATIC_NAME) $(WHOLE_NOARCHIVE)
+else
+# The standalone compiler-rt build is based on
+# https://github.com/ReservedField/arm-compiler-rt


attribute completely https://github.com/ReservedField/arm-compiler-rt/blob/0fcfe9a2e4292e66fa0148479eb71f37d04381b2/LICENSE#L12-L13

I did not reuse code, but I was inspired by the way they solved the build issue., but I can add the copyright notice

hm okay, "based on" is a bit ambiguous

tkelman · 2016-09-29T21:57:12Z

deps/compiler-rt.mk

+extract-compiler-rt: $(COMPILER_RT_SRCDIR)/source-extracted
+endif
+check-compiler-rt: #NONE
+fast-check-compiler-rt: #NONE


fastcheck-compiler-rt

tkelman · 2016-09-29T21:58:18Z

deps/compiler-rt.mk

+	rm -rf $(COMPILER_RT_BUILDDIR)
+compile-compiler-rt: $(COMPILER_RT_BUILDDIR)/$(COMPILER_RT_LIBFILE)
+install-compiler-rt: $(COMPILER_RT_BUILDDIR)/$(COMPILER_RT_LIBFILE)
+	cp $(COMPILER_RT_BUILDDIR)/$(COMPILER_RT_LIBFILE) $(build_private_libdir)/


this will need to use one of the confusing install macros to support uninstall. might also need a manifest file, however those are supposed to work

not yet addressed

@vtjnash When I discussed this with you, you mentioned that I might not need to use the macro since I only install two files?
I am also happy to use the staged-install mechanism, but I hadn't had time to understand it yet.

tkelman · 2016-09-29T21:59:22Z

src/jitlayers.cpp

+    static const char *const prefix = "__";
+    if (!compiler_rt_hdl)
+        return 0;
+    if (strncmp(name, prefix, strlen(prefix) != 0))


is this supposed to be if (strncmp(name, prefix, strlen(prefix)) != 0) ?

vtjnash · 2016-09-30T15:43:35Z

deps/compiler-rt.mk

+CRT_ARCH_SRCDIR := $(CRT_SRCDIR)/$(CRT_ARCH)
+CRT_INCLUDES := -I$(CRT_SRCDIR) -I$(CRT_ARCH_SRCDIR)
+CRT_CFLAGS := \
+		-std=gnu99 -fPIC -fno-builtin -fvisibility=hidden \


$(fPIC)
does -fvisibility=hidden do the same thing everywhere?
also might need to check on -ffreestanding

vtjnash · 2016-09-30T15:45:46Z

deps/compiler-rt.mk

+CRT_CFLAGS := \
+		-std=gnu99 -fPIC -fno-builtin -fvisibility=hidden \
+		-ffreestanding $(CRT_INCLUDES)\
+		$(if $(USE_CLANG), -Wno-unknown-attributes -Wno-macro-redefined)


Our usual style for this has been to split it onto separate lines, but perhaps not universal:

ifeq ($(USE_CLANG),1) CRT_CFLAGS += ... endif

vtjnash · 2016-09-30T15:51:21Z

deps/compiler-rt.mk

+CRT_SRCDIR := $(COMPILER_RT_SRCDIR)/lib/builtins
+CRT_ARCH_SRCDIR := $(CRT_SRCDIR)/$(CRT_ARCH)
+CRT_INCLUDES := -I$(CRT_SRCDIR) -I$(CRT_ARCH_SRCDIR)
+CRT_CFLAGS := \


add $(CPPFLAGS) $(CFLAGS) too

shouldn't this have -O2 also?

vtjnash · 2016-09-30T15:53:02Z

deps/compiler-rt.mk

+	$(CC) $(CRT_CFLAGS) -c $< -o $@
+
+$(COMPILER_RT_BUILDDIR)/$(COMPILER_RT_LIBFILE): $(CRT_OBJS)
+	$(CC) -shared -o $@ $^


does this need -fvisibility=hidden?

add $(LDFLAGS) here too

vtjnash · 2016-09-30T15:54:23Z

deps/compiler-rt.mk

+endif
+
+$(COMPILER_RT_SRCDIR)/source-extracted: | $(COMPILER_RT_TAR)
+ifneq ($(COMPILER_RT_TAR),)


I don't think this rule makes sense overall if COMPILER_RT_TAR is empty

vtjnash · 2016-09-30T15:58:51Z

deps/llvm.mk

+LLVM_MFLAGS += OPTIONAL_PARALLEL_DIRS=
+endif
+else
+ifeq ($(LLVM_VER_SHORT),$(filter $(LLVM_VER_SHORT),3.3 3.4 3.5 3.6 3.7))


USE_LLVM_CMAKE?

vchuravy · 2016-09-30T21:01:17Z

Updated the PR to address the feedback given so far. I run into two major annoyances the first is that LLVM 3.9 can't build compiler-rt without clang and that the way I discover the files is problematic, because it relies on the source being already unpacked. @vtjnash suggested splitting the Makefiles, but I was hoping that somebody else might have a better solution.

tkelman · 2016-10-03T01:00:08Z

Make.inc

-# set to 1 to build compiler-rt standalone.
-STANDALONE_COMPILER_RT := 0
+# set to 0 to disable building compiler-rt standalone.
+# Currently compiler-rt can only be build alongside clang


can only be built

vchuravy · 2016-10-04T08:15:25Z

So travis for Linux is passing. Yeah! I will see if I can get my hand on a Mac.

@yuyichao If you have time would you mind taking a look at ARM? The build-script might need some adjustments to pick up the right Arch implementations and blacklist unnecessary ones.

vchuravy · 2016-10-05T05:18:27Z

So I fixed ARM&Power + Mac. The remaining platform is windows (which I don't have access to at the moment)

tkelman · 2016-10-05T10:13:42Z

Try cross-compiling?

tkelman · 2016-10-08T13:32:49Z

Make.inc

@@ -481,10 +486,13 @@ OBJCOPY := $(CROSS_COMPILE)objcopy
 # file extensions
 ifeq ($(OS), WINNT)
  SHLIB_EXT := dll
+  STATICLIB_EXT := lib


only with msvc. where are you dealing with a lib file?

Also under mingw64? ce33683 changed that we are now linking sys.so statically against compiler-rt.

no, mingw static libraries are .a extension. compiler-rt's build system is probably full of wrong windows==msvc assumptions that should be fixed rather than worked around the wrong way here

Okay, I will fix this in the morning (It was my wrong assumption, not compiler-rts)

Is there a way of detecting the compiler from the Makefile?

there's a USEMSVC or some flag like that but it's a hack, you probably shouldn't worry about it. if we ever support msvc properly it'll be via cmake anyway.

So just changing lib to a would be sufficient for now?

vchuravy · 2016-10-08T13:51:23Z

So with build support for Windows, Mac, ARM, Power this is ready for another round of reviews, before I squash and rebase.

tkelman · 2016-10-09T11:44:09Z

Make.inc

@@ -486,7 +486,7 @@ OBJCOPY := $(CROSS_COMPILE)objcopy
 # file extensions
 ifeq ($(OS), WINNT)
  SHLIB_EXT := dll
-  STATICLIB_EXT := lib
+  STATICLIB_EXT := .a # MSVC is .lib


if comments are on the same line in a makefile variable, the value will include the trailing space - this might not break anything, but keep it in mind

tkelman · 2016-10-09T15:52:11Z

Make.inc

@@ -486,7 +486,11 @@ OBJCOPY := $(CROSS_COMPILE)objcopy
 # file extensions
 ifeq ($(OS), WINNT)
  SHLIB_EXT := dll
-  STATICLIB_EXT := a # MSVC is lib
+ifeq ($(USE_MSVC),1)


no underscore

I should really stop pushing commits late night. Thank you for catching this.

vchuravy · 2016-10-10T12:57:08Z

src/jitlayers.cpp

+static uint64_t resolve_compiler_rt(const char *name)
+{
+#if defined(__APPLE__)
+    static const char *const compiler_rt_lib = "@rpath/julia/libcompiler-rt";


@vtjnash Is this the correct form for a rpath library? Or do I need to add .dylib?

tkelman · 2016-10-10T13:10:53Z

Makefile

@@ -374,7 +374,11 @@ endif
 	$(INSTALL_F) $(addprefix $(JULIAHOME)/,src/julia.h src/julia_threads.h src/support/*.h) $(DESTDIR)$(includedir)/julia
 	$(INSTALL_F) $(BUILDROOT)/src/julia_version.h $(DESTDIR)$(includedir)/julia
 	# Copy julia's copy of compiler-rt
+ifeq ($(OS),WINNT)
+	$(INSTALL_M) $(build_private_libdir)/libcompiler-rt.$(SHLIB_EXT) $(DESTDIR)$(bindir)
+else
 	$(INSTALL_M) $(build_private_libdir)/libcompiler-rt.$(SHLIB_EXT) $(DESTDIR)$(private_libdir)


why isn't this just using shlibdir then?

vchuravy · 2016-10-11T03:01:50Z

Ok this is nearly done. Mac test just succeeded From worker 9: * llvmcall maxrss 199.11 MB.

I would squash this and remove the debug information (or does anybody want to keep the poetry and the history for reviewing?)

vchuravy · 2016-10-11T06:52:59Z

Original version preserved at ~~https://github.com/JuliaLang/julia/tree/vc/crt_backup~~ https://github.com/JuliaGPU/julia/tree/vc/crt_backup

tkelman · 2016-10-11T07:47:12Z

Can you move that to your fork? Would rather clean up no-longer-relevant branches from here.

This still doesn't support uninstall, does it?

vchuravy · 2016-10-11T07:53:05Z

Uninstall? You mean clean-compiler-rt?

On Tue, 11 Oct 2016, 16:47 Tony Kelman, [email protected] wrote:

Can you move that to your fork? Would rather clean up no-longer-relevant
branches from here.

This still doesn't support uninstall, does it?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#18734 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI3agWewdyu5rVQu9H6iGM7Y99YHeAJks5qyz8BgaJpZM4KKgMs
.

tkelman · 2016-10-11T08:31:42Z

no, uninstall-compiler-rt - remove the installed files from the install prefix. clean removes them from the build location

tkelman · 2016-10-11T08:32:07Z

src/jitlayers.cpp

@@ -324,7 +324,7 @@ static uint64_t resolve_compiler_rt(const char *name)
    // jl_dlsym_e expects an unmangled 'C' symbol name,
    // so iff we are on Darwin we strip the leading '_' off.
    static const char *const mangled_prefix = "___";
-    if (strncmp(name, mangled_prefix, strlen(mangled_prefix)) != 0) {
+    if (strncmp(name, mangled_prefix, strlen(mangled_prefix)) == 0) {
      ++name;


tkelman · 2016-10-11T08:50:14Z

deps/compiler-rt.mk

@@ -135,12 +135,14 @@ fastcheck-compiler-rt: #NONE
 configure-compiler-rt: $(COMPILER_RT_BUILDDIR)/build-configured
 clean-compiler-rt:


I think clean should depend on uninstall, most of the autogenerated ones do IIRC

makefiles are awful

tkelman · 2016-10-11T12:08:45Z

Can I request that we hold off on merging anything LLVM build related until we're sure the buildbots are in good shape and will handle it? We haven't had nightlies in several weeks, and it looks like there are some new consistent failures within the last few days.

vchuravy · 2016-11-12T01:08:26Z

I did not manage to reproduce the buildbot failure :(

Maybe the best course of actions is to wait on #19123 and the associated buildbot changes?

tkelman · 2016-12-29T23:40:32Z

Rebased this for you to pick up llvm 3.9, ran it through the buildbots. 32 bit Linux still has issues, segfaults when trying to build the docs: https://build.julialang.org/builders/package_tarball32/builds/1140/steps/make%20binary-dist/logs/stdio

And on Windows, it's trying to use pthreads. We can't switch our compiler version on Windows to one that supports pthreads for as long as we need to be able to build Windows binaries against LLVM 3.7 on the same buildbots.

emutls.o:emutls.c:(.text+0x13): undefined reference to `pthread_key_create'
emutls.o:emutls.c:(.text+0x8d): undefined reference to `pthread_getspecific'
emutls.o:emutls.c:(.text+0xcf): undefined reference to `pthread_once'
emutls.o:emutls.c:(.text+0xdb): undefined reference to `pthread_mutex_lock'
emutls.o:emutls.c:(.text+0xf4): undefined reference to `pthread_mutex_unlock'
emutls.o:emutls.c:(.text+0x14f): undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:81: libcompiler-rt.dll] Error 1

vchuravy · 2016-12-30T02:51:00Z

deps/compiler-rt_standalone.mk

+# Blacklist a few files we don't want to deal with
+##
+MAKEFLAGS := --no-builtin-rules
+BLACKLIST := atomic.o atomic_flag_clear.o atomic_flag_clear_explicit.o \


@tkelman the emutls failure means we need to update the blacklist to contain the related files

commit that and we could try throwing it at the buildbots again?

looks like that fixes the windows build (need to run tests locally, will see) but not whatever's wrong with the 32 bit linux buildbot

Compiler-rt is the runtime library of LLVM and sometimes we need to resolve library calls to it. There are two moments were we need to handle library calls to compiler-rt. 1. `sys.so` or any other Julia code compiled into shlibs. In this case we perform static linking, as with other runtime libraries. 2. JIT time. When we compile a Julia function that uses a libcall to crt we need to resolve that against a shlib copy of compiler-rt. Compiler-rt is usually only distributed as a static library, so we provide a step to turn the static library into a shared one. The buildsystem of compiler-rt is tightly tied to LLVM. Because of this we have a staged build-script that builds compiler-rt from source. This standalone version should only be used for Julia.

LLVM intrinsics either map to instructions or to functions in compiler-rt. If we can't find a symbol look into a shared version of compiler-rt and resolve the functions there. On Darwin we have to use a unmangled version of the function name.

One most systems (except modern mac) these tests will fail if compiler-rt is not properly configured.

staticfloat · 2017-01-01T09:08:01Z

Running on 32-bit linux (inside a Docker container) I get through bootstrap, but then I get a segfault when I try to run ./julia. Here's the backtrace:

(gdb) bt
#0  0xf7fe479d in elf_machine_rel (skip_ifunc=<optimized out>,
    reloc_addr_arg=<optimized out>, version=<optimized out>, sym=0xf30da45c,
    reloc=0xf313708c, map=0x805d320) at ../sysdeps/i386/dl-machine.h:312
#1  elf_dynamic_do_Rel (skip_ifunc=<optimized out>, lazy=<optimized out>,
    nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>,
    map=<optimized out>) at do-rel.h:137
#2  _dl_relocate_object (scope=0x805d4d8, reloc_mode=0, consider_profiling=0)
    at dl-reloc.c:258
#3  0xf7fec6bf in dl_open_worker (a=0xffffce9c) at dl-open.c:435
#4  0xf7fe8204 in _dl_catch_error (objname=objname@entry=0xffffce94,
    errstring=errstring@entry=0xffffce98, mallocedp=mallocedp@entry=0xffffce93,
    operate=0xf7fec370 <dl_open_worker>, args=0xffffce9c) at dl-error.c:187
#5  0xf7febf02 in _dl_open (file=0xffffd160 "/src/julia/usr/lib/julia/sys.so",
    mode=-2147483646, caller_dlopen=0xf7d017da <jl_dlopen+119>, nsid=<optimized out>,
    argc=1, argv=0xffffd644, env=0xffffd64c) at dl-open.c:660
#6  0xf7cacbf5 in dlopen_doit (a=0xffffd050) at dlopen.c:66
#7  0xf7fe8204 in _dl_catch_error (objname=0x805d2ec, errstring=0x805d2f0,
    mallocedp=0x805d2e8, operate=0xf7cacb80 <dlopen_doit>, args=0xffffd050)
    at dl-error.c:187
#8  0xf7cad30d in _dlerror_run (operate=operate@entry=0xf7cacb80 <dlopen_doit>,
    args=args@entry=0xffffd050) at dlerror.c:163
#9  0xf7cacc9e in __dlopen (
    file=file@entry=0xffffd160 "/src/julia/usr/lib/julia/sys.so", mode=2) at dlopen.c:87
#10 0xf7d017da in jl_dlopen (
    filename=filename@entry=0xffffd160 "/src/julia/usr/lib/julia/sys.so",
    flags=flags@entry=9) at /src/julia/src/dlload.c:81
#11 0xf7d01a8b in jl_load_dynamic_library_ (
    modname=modname@entry=0xffffd390 "/src/julia/usr/lib/julia/sys",
    flags=flags@entry=9, throw_err=throw_err@entry=0) at /src/julia/src/dlload.c:179
#12 0xf7d01b8a in jl_load_dynamic_library_e (
    modname=0xffffd390 "/src/julia/usr/lib/julia/sys", flags=flags@entry=9)
    at /src/julia/src/dlload.c:204
#13 0xf7d11ddb in jl_preload_sysimg_so (fname=<optimized out>)
    at /src/julia/src/dump.c:2367
#14 0xf7d04558 in _julia_init (rel=<optimized out>, rel@entry=JL_IMAGE_JULIA_HOME)
    at /src/julia/src/init.c:532
#15 0xf7d0510c in julia_init (rel=JL_IMAGE_JULIA_HOME) at /src/julia/src/task.c:292
#16 0x08048f7c in main (argc=<optimized out>, argv=<optimized out>)
    at /src/julia/ui/repl.c:251

This was done through the following, you can do it too if you have docker installed:

$ docker run -ti staticfloat/julia_workerbase_ubuntu16_04:x86
# git clone -b vc/compiler-rt https://github.com/JuliaLang/julia /src/julia
# cd /src/julia; make -j8

vchuravy · 2017-01-01T15:15:02Z

Interesting that it seqfaults when dlopen'ing the `sys.so`. Could you check if the imagine only contains 32bit instructions?

…

On Sun, 1 Jan 2017, 18:08 Elliot Saba, ***@***.***> wrote: Running on 32-bit linux (inside a Docker container) I get through bootstrap, but then I get a segfault when I try to run ./julia. Here's the backtrace: (gdb) bt #0 0xf7fe479d in elf_machine_rel (skip_ifunc=<optimized out>, reloc_addr_arg=<optimized out>, version=<optimized out>, sym=0xf30da45c, reloc=0xf313708c, map=0x805d320) at ../sysdeps/i386/dl-machine.h:312 #1 elf_dynamic_do_Rel (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=<optimized out>) at do-rel.h:137 #2 _dl_relocate_object (scope=0x805d4d8, reloc_mode=0, consider_profiling=0) at dl-reloc.c:258 #3 0xf7fec6bf in dl_open_worker (a=0xffffce9c) at dl-open.c:435 #4 0xf7fe8204 in _dl_catch_error ***@***.***=0xffffce94, ***@***.***=0xffffce98, ***@***.***=0xffffce93, operate=0xf7fec370 <dl_open_worker>, args=0xffffce9c) at dl-error.c:187 #5 0xf7febf02 in _dl_open (file=0xffffd160 "/src/julia/usr/lib/julia/sys.so", mode=-2147483646, caller_dlopen=0xf7d017da <jl_dlopen+119>, nsid=<optimized out>, argc=1, argv=0xffffd644, env=0xffffd64c) at dl-open.c:660 #6 0xf7cacbf5 in dlopen_doit (a=0xffffd050) at dlopen.c:66 #7 0xf7fe8204 in _dl_catch_error (objname=0x805d2ec, errstring=0x805d2f0, mallocedp=0x805d2e8, operate=0xf7cacb80 <dlopen_doit>, args=0xffffd050) at dl-error.c:187 #8 0xf7cad30d in _dlerror_run ***@***.***=0xf7cacb80 <dlopen_doit>, ***@***.***=0xffffd050) at dlerror.c:163 #9 0xf7cacc9e in __dlopen ( ***@***.***=0xffffd160 "/src/julia/usr/lib/julia/sys.so", mode=2) at dlopen.c:87 #10 0xf7d017da in jl_dlopen ( ***@***.***=0xffffd160 "/src/julia/usr/lib/julia/sys.so", ***@***.***=9) at /src/julia/src/dlload.c:81 #11 0xf7d01a8b in jl_load_dynamic_library_ ( ***@***.***=0xffffd390 "/src/julia/usr/lib/julia/sys", ***@***.***=9, ***@***.***=0) at /src/julia/src/dlload.c:179 #12 0xf7d01b8a in jl_load_dynamic_library_e ( modname=0xffffd390 "/src/julia/usr/lib/julia/sys", ***@***.***=9) at /src/julia/src/dlload.c:204 #13 0xf7d11ddb in jl_preload_sysimg_so (fname=<optimized out>) at /src/julia/src/dump.c:2367 #14 0xf7d04558 in _julia_init (rel=<optimized out>, ***@***.***=JL_IMAGE_JULIA_HOME) at /src/julia/src/init.c:532 #15 0xf7d0510c in julia_init (rel=JL_IMAGE_JULIA_HOME) at /src/julia/src/task.c:292 #16 0x08048f7c in main (argc=<optimized out>, argv=<optimized out>) at /src/julia/ui/repl.c:251 This was done through the following, you can do it too if you have docker installed: $ docker run -ti staticfloat/julia_workerbase_ubuntu16_04:x86 # git clone -b vc/compiler-rt https://github.com/JuliaLang/julia /src/julia # cd /src/julia; make -j8 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#18734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI3avgIaLIoVJN6UYQp8BB8TriJaE_1ks5rN2zygaJpZM4KKgMs> .

staticfloat · 2017-01-01T20:47:00Z

Yep, looks good to me. Using analyze-x86 shows:

./analyze-x86 /src/julia/usr/lib/julia/sys.so
instructions:
 cpuid: 0        nop: 1057       call: 109406    count: 1393634
 i486:   58
 i686:   5159
 mmx:    465
 sse:    1226
 sse2:   8087

Note that this output is from my fork of analyze-x86 which knows what AVX instructions look like.

felixrehren · 2017-02-15T09:35:23Z

Ping (this is part of equal rights for Float16, right?)

StefanKarpinski · 2017-02-15T19:50:28Z

It's good to have, but it was deemed not ready for 0.6, unfortunately.

vchuravy · 2017-02-16T03:48:57Z

Yes this part of my julia runtime julep, that has the goal of adding first-class support for Float16 and Float128. This got slowed down by other commitments of mine. I still have hope to have some form of this for 1.0.

StefanKarpinski · 2017-07-20T17:51:11Z

@vchuravy, what's the prospect for getting this done in the next couple of months?

vchuravy · 2017-07-24T07:36:47Z

Everytime I start working on this I get into shaving another Yak. I think we can get this done in the next few months, but I will first focus on Float128 and then return to this.

vchuravy · 2018-03-09T00:30:59Z

superseded by #26381, while general compiler-rt support might be something we want in the long-term I rather go down the RTLIB approach.

tkelman reviewed Sep 29, 2016

View reviewed changes

vtjnash reviewed Sep 30, 2016

View reviewed changes

vchuravy force-pushed the vc/compiler-rt branch 2 times, most recently from 37f9286 to 6a0940c Compare September 30, 2016 20:58

tkelman reviewed Oct 3, 2016

View reviewed changes

vchuravy force-pushed the vc/compiler-rt branch 2 times, most recently from 6fa6d5a to e78a328 Compare October 4, 2016 08:12

vchuravy mentioned this pull request Oct 6, 2016

[RFC/WIP] Leverage compiler-rt for builtins support of llvm intrinsics #17344

Closed

3 tasks

tkelman reviewed Oct 8, 2016

View reviewed changes

tkelman reviewed Oct 9, 2016

View reviewed changes

vchuravy force-pushed the vc/compiler-rt branch from 1bc4ec6 to 935be6e Compare October 10, 2016 03:42

vchuravy commented Oct 10, 2016

View reviewed changes

tkelman reviewed Oct 10, 2016

View reviewed changes

vchuravy force-pushed the vc/compiler-rt branch from af59013 to 1a9af7f Compare October 10, 2016 22:55

vchuravy force-pushed the vc/compiler-rt branch from 278bedb to 7d1cbae Compare October 11, 2016 06:52

tkelman reviewed Oct 11, 2016

View reviewed changes

vchuravy added this to the 0.6.0 milestone Oct 11, 2016

This was referenced Nov 1, 2016

role-epel missing staticfloat/julia-ansible-scripts#3

Open

RTLIB: A runtime-library for Julia JuliaLang/Juleps#11

Merged

vchuravy mentioned this pull request Nov 11, 2016

is Float16 a real computational type or not? #5942

Closed

vchuravy force-pushed the vc/compiler-rt branch from 1dbb7fd to 2f8a69d Compare December 27, 2016 06:56

tkelman force-pushed the vc/compiler-rt branch from 2f8a69d to 25b985b Compare December 29, 2016 23:25

vchuravy commented Dec 30, 2016

View reviewed changes

vchuravy added 3 commits December 31, 2016 16:37

adds test for llvm intrinsics

34de984

One most systems (except modern mac) these tests will fail if compiler-rt is not properly configured.

vchuravy force-pushed the vc/compiler-rt branch from 25b985b to 34de984 Compare December 31, 2016 07:37

StefanKarpinski modified the milestones: 1.0, 0.6.0 Jan 5, 2017

StefanKarpinski modified the milestones: 1.x, 1.0 Jul 20, 2017

vchuravy mentioned this pull request Mar 9, 2018

Switch Float16 LLVM representation from i16 to half #26381

Closed

vchuravy closed this Mar 9, 2018

maleadt mentioned this pull request Sep 10, 2020

Switch Float16 to LLVM's half #37510

Merged

vchuravy mentioned this pull request Oct 23, 2020

LLVM ERROR: Program used external function '__multi3' which could not be resolved! #29447

Open

DilumAluthge deleted the vc/compiler-rt branch March 25, 2021 22:09

		@@ -135,12 +135,14 @@ fastcheck-compiler-rt: #NONE
		configure-compiler-rt: $(COMPILER_RT_BUILDDIR)/build-configured
		clean-compiler-rt:

Basic support for builtins from compiler-rt #18734

Basic support for builtins from compiler-rt #18734

Conversation

vchuravy commented Sep 29, 2016 • edited Loading

Caveats

TODO

Choose a reason for hiding this comment

tkelman Sep 29, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkelman Sep 29, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vtjnash Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vchuravy commented Sep 30, 2016

Choose a reason for hiding this comment

vchuravy commented Oct 4, 2016

vchuravy commented Oct 5, 2016

tkelman commented Oct 5, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vchuravy commented Oct 8, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vchuravy commented Oct 11, 2016

vchuravy commented Oct 11, 2016 • edited Loading

tkelman commented Oct 11, 2016

vchuravy commented Oct 11, 2016

tkelman commented Oct 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkelman commented Oct 11, 2016

vchuravy commented Nov 12, 2016 • edited Loading

tkelman commented Dec 29, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staticfloat commented Jan 1, 2017

vchuravy commented Jan 1, 2017 via email

staticfloat commented Jan 1, 2017 • edited Loading

felixrehren commented Feb 15, 2017

StefanKarpinski commented Feb 15, 2017

vchuravy commented Feb 16, 2017

StefanKarpinski commented Jul 20, 2017

vchuravy commented Jul 24, 2017

vchuravy commented Mar 9, 2018

vchuravy commented Sep 29, 2016 •

edited

Loading

tkelman Sep 29, 2016 •

edited

Loading

tkelman Sep 29, 2016 •

edited

Loading

vtjnash Sep 30, 2016 •

edited

Loading

vchuravy commented Oct 11, 2016 •

edited

Loading

vchuravy commented Nov 12, 2016 •

edited

Loading

staticfloat commented Jan 1, 2017 •

edited

Loading