| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Removes a non-ascii character that was committed.
llvm-svn: 217353
|
|
|
|
|
|
|
|
|
| |
Add the missing AEABI functions that are part of the base platform ABI
specification. The provided implementation does the bare minimum to avoid
requiring libc headers. This permits the use of compiler-rt on bare-metal
environments which conform to EABI.
llvm-svn: 217322
|
|
|
|
|
|
|
| |
This macro did not do anything at this point, and is not particularly needed for
Windows unless building the builtins as a shared library. NFC.
llvm-svn: 217321
|
|
|
|
|
|
|
| |
Add a helpful description and a signature for the functions implemented in
assembly for the integral math routines. NFC.
llvm-svn: 215296
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building the builtins for a modern CPU (idiv support), __umodsi3 was
completely incorrect as it would behave as __udivmosi3, which takes a tertiary
parameter which is a pointer.
__udivsi3 was also incorrect, returning the remainder in r1. Although this
would not result in any crash or invalid behaviour as r1 is a caller saved
register in AAPCS, this is unnecessary. Simply perform the division ignoring
the remainder.
llvm-svn: 215295
|
|
|
|
|
|
|
|
|
|
| |
The LLVM IAS seems to accept wide instructions for add and sub in ARM mode even
though it is not permitted. This uses a macro to ensure that the wide modifier
is only applied when building in THUMB mode.
This repairs building with GCC/GAS in ARM mode.
llvm-svn: 214046
|
|
|
|
|
|
|
| |
The macro definitions are shared across multiple files. Define them once in the
assembly.h header rather than redefining it in each file.
llvm-svn: 214045
|
|
|
|
| |
llvm-svn: 214044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The architecture specific implementation of routines would be built and included
along with the generic implementation. This would result in multiple
definitions of those symbols.
The linker is free to select either of the two. Most of the time, this
shouldn't be too terrible as the forward iteration should catch the architecture
version due to the ordering. Rather than relying on the linker and build
infrastructure ordering things in a specific manner, only provide the
architecture version when available.
This reduces the size of compiler-rt, simplifies inspection of the library
implementations, and guarantees that the desired version is selected at a
slightly complex build system.
llvm-svn: 214040
|
|
|
|
|
|
|
| |
This adds missed files in SVN r214033 for alignment and corrects a change from
SVN r214034 for fixing compilation with GCC.
llvm-svn: 214039
|
|
|
|
|
|
|
| |
Place the floating point constants into the read-only data section. This was
already being done for x86_64, this simply mirrors the behaviour for i686.
llvm-svn: 214034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MMX/SSE instructions expect 128-bit alignment (16-byte) for constants that they
reference. Correct the alignment on the constant values. Although it is quite
possible for the data to end up aligned, there is no guarantee that this will
occur unless it is explicitly aligned to the desired location. If the data ends
up being unaligned, the resultant binary would fault at runtime due to the
unaligned access.
As an example, the follow would fault previously:
cc -c lib/builtins/x86_64/floatundidf.S -o floatundidf.o
cc -c test/builtins/Unit/floatundidf_test.c -o floatundidf_test.c
ld -m elf_x86_64 floatundidf.o floatundidf_test.o -lc -o floatundidf
However, if the object files were reversed, the data would end up aligned and
the problem would go unnoticed.
llvm-svn: 214033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply SVN r213684 which was reverted in SVN r213724 since it broke the
build bots. Add a tweak to enable inclusion of the assembly sources in
standalone build as well.
Original commit message:
This patch address the PR20360. The CMake assembler build system
ignores the .S assembly files in builtins library build. This patch
fixes the issue.
llvm-svn: 214013
|
|
|
|
|
|
|
|
|
|
|
|
| |
The .rodata directive was added on the IA-64 (Itanium) platform. The LLVM IAS
supports the .rodata on i386 and x86_64 as well. There is no reason to really
restrict compilation of the builtins to just clang. By explicitly indicating
that the data is meant to be pushed into the .rodata section via the .section
.rodata, the assembly is made compatible with clang and gcc (with GAS).
This will enable building these routines on the Linux buildbots via CMake.
llvm-svn: 214012
|
|
|
|
|
|
|
| |
This reverts commit r213684, since it was breaking the compiler-rt
build and the sanitizers' bot.
llvm-svn: 213724
|
|
|
|
|
|
|
|
|
|
| |
Convert the CBNZ backward branch instruction to CMP and BNE
avoiding illegal backwards branch and making the assembly code
in synh-ops.h to be UAL compliant.
Patch by: Sumanth Gundapaneni
llvm-svn: 213685
|
|
|
|
|
|
|
|
|
| |
The CMake assembler build system ignores the .S assembly files in builtins
library build. This patch fixes the issue.
Patch by: Sumanth Gundapaneni
llvm-svn: 213684
|
|
|
|
|
|
| |
Discussed with and tested by: Saleem Abdulrasool
llvm-svn: 213481
|
|
|
|
| |
llvm-svn: 213479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ARM cores that are ARMv6T2+ but not ARMv7ve or ARMv7-r and not an updated
ARMv7-a that has the idiv extension (chips with clz but not idiv), an incorrect
jump would be calculated due to the preference to thumb instructions over ARM.
Rather than computing the target at runtime, use a jumptable instead. This
trades a bit of storage for performance. The overhead is 32-bytes for each of
the three routines, but avoid the calculation of the offset.
Because clz was introduced in ARMv6T2 and idiv in certain versions of ARMv7,
the non-clz, non-idiv case implies a target which does not support Thumb-2, and
thus we cannot use Thumb on those targets (as it is unlikely that the assembly
will assemble).
Take the opportunity to refactor the IT block macros into assembly.h rather than
redefining them in the TUs where they are used.
Existing tests cover the full change already, so no new tests are added.
This effectively reverts SVN r213309.
llvm-svn: 213467
|
|
|
|
|
|
|
|
|
| |
The udivmodsi4/modsi3/umodsi3 code computes jump targets based on ARM encodings
(if CLZ is present and IDIV is not present).
Reverts parts of r211032 and r211035.
llvm-svn: 213309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builds things.
Without some mention of armv6m in a subdirectory of builtins, the make code
doesn't even know that armv6m exists and is something it should be looking for
in the platform-specific Makefiles. This means that none of the functions
listed actually get built and we end up with an almost entirely empty
libclang_rt.a for armv6m.
Unfortunately, the assembly code in the usual arm directory has no hope of
running on armv6m, which only supports Thumb-1 (not even ARM mode), so adding
it there won't work. Realistically, we probably *will* want to put any
optimised versions in a separate directory, so creating it now is harmless.
rdar://problem/17613576
llvm-svn: 212696
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3909
llvm-svn: 212518
|
|
|
|
|
|
|
|
|
| |
Storage Class 3 is static storage. These symbols need to be marked as external
(storage class 2) so that they can be referenced. Note that this external is
not the same as ELF "external" visibility, which is indicated by DLL Storage
Class (i.e. __declspec(dllexport) or __declspec(dllimport)).
llvm-svn: 211428
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D2799
llvm-svn: 211313
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D2798
llvm-svn: 211312
|
|
|
|
|
|
|
| |
Add the missing IT-blocks for Thumb-2 compilation for code paths exercised by
older ARM CPUs. This should fix the buildbots.
llvm-svn: 211035
|
|
|
|
|
|
|
|
|
|
|
| |
When possible, use Thumb or Thumb-2 over ARM instructions. This is particularly
important for pure-Thumb environments (e.g. Windows on ARM). Although, it is
possible to conditionalise this for that target specifically, this is available
on most newer ARM CPUs, and the code remains compatible with older CPUs with no
adverse effects. It therefore feels better to always prefer Thumb when
possible.
llvm-svn: 211032
|
|
|
|
|
|
|
|
| |
Place constants into .rdata if targeting ELF or COFF/PE. This should be
functionally identical, however, the data would be placed into a different
section. This is purely a cleanup change.
llvm-svn: 209986
|
|
|
|
|
|
|
|
|
| |
Make the whitespace a bit more uniform in the various assembly routines. This
also makes the assembly files a bit more uniform on the ARM side by explicitly
stating that it is using the unified syntax and that the contents of the code is
in the text section (or segment). No functional change.
llvm-svn: 209985
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D2800
llvm-svn: 209886
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D2802
llvm-svn: 209783
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D2803
llvm-svn: 209782
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3887
llvm-svn: 209781
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3888
llvm-svn: 209779
|
|
|
|
|
|
|
|
| |
And fixed typos in the ASan readme.
Differential Revision: http://reviews.llvm.org/D3927
llvm-svn: 209778
|
|
|
|
|
|
|
| |
Patch from: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3886
llvm-svn: 209741
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3885
llvm-svn: 209740
|
|
|
|
|
|
|
|
|
|
| |
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209473
|
|
|
|
|
|
| |
GCC and that doesn't expose any *ti* functions either.
llvm-svn: 209133
|
|
|
|
|
|
|
|
|
| |
Extend the function definition macros further to support COFF object emission.
The function definition in COFF includes the type and storage class in the
symbol definition context. This is needed to make the assembly routines
possible to be built for COFF environments (i.e. Windows).
llvm-svn: 209095
|
|
|
|
|
|
|
|
| |
Rename the HIDDEN_DIRECTIVE macro to HIDDEN and give it a parameter providing
the name of the symbol to be given hidden visibility. This makes the macros
more amenable to COFF.
llvm-svn: 209094
|
|
|
|
|
|
| |
Reformat assembly.h with clang-format. NFC.
llvm-svn: 208950
|
|
|
|
| |
llvm-svn: 208841
|
|
|
|
| |
llvm-svn: 208603
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Use .balign instead of .p2align 3. This should fix the buildbots.
llvm-svn: 208585
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|