Add (missing) definition of COMPILER_RT_EXPORT which is meant to be used for
decorating functions that are meant to be exported. This is useful for
platforms where exports and imports must be decorated explicitly (i.e. Windows).
llvm-svn: 208593
Use COMPILER_RT_EXPORT rather than COMPILER_RT_ABI for this function. Adding an
explicit PCS standard to the function causes a mismatch between the
declarations. Furthermore, the function is implemented in C, and should take
the CC based on the target triple.
llvm-svn: 208591
The .align statements in ARM assembly routines is actually meant to be a power
of 2 alignment (e.g. .align 2 == 4 byte alignment, not 2). Switch to using
.p2align. .p2align is guaranteed to be a power-of-two alignment always and much
more explicit.
The .align in the case of x86_64 is byte alignment, use .balign instead of
.align.
llvm-svn: 208578
r201909, which introduced CRT_HAS_128BIT, unintentionally broke self-hosting on
PPC32. We used to define CRT_HAS_128BIT only on LP64 systems, but this is not
quite right (at least for Clang-compiled code). Even though __int128 is not
supported on PPC32, SROA can (and does) still form i128 variables at the IR
level, and operations on those variables may turn into the associated runtime
calls. As a result, we still need to compile __ashlti3, __ashrti3, __lshrti3,
and perhaps others, on PPC32.
llvm-svn: 208560
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
negative shift amounts and/or shifts wider than the type. VAX traps on
the former, X86 and other platforms produce incorrect results on the
latter.
llvm-svn: 204193
Since these are primarily useful for deeply embedded targets where code size is
very important, they are each in a separate file making use of infrastructure
in sync-ops.h. This allows a linker to include just the functions that are
actually used.
rdar://problem/14736665
llvm-svn: 202812
This reverts commit r201910.
While __func__ may be standard in C++11, it was only recently added to
MSVC in 2013 CTP, and LLVM supports MSVC 2012. __FUNCTION__ may not be
standard, but it's *very* portable.
llvm-svn: 201916
Alp Toker