| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isinf (is infinite) and isfinite should be implemented with the same function
except we change the comparison operator.
See PR27145 for more details:
https://llvm.org/bugs/show_bug.cgi?id=27145
Ref: forked off of the discussion in D18513.
Differential Revision: http://reviews.llvm.org/D18648
llvm-svn: 265675
|
|
|
|
|
|
| |
Also add documentation for bitreverse builtins
llvm-svn: 264203
|
|
|
|
| |
llvm-svn: 262122
|
|
|
|
|
|
|
| |
Follow the naming convention that bswap uses since it's a
similar sort of operation.
llvm-svn: 259671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow, we never managed to implement this fully. We could constant
fold it like crazy, including constant folding complex arguments, etc.
But if you actually needed to generate code for it, error.
I've implemented it using the somewhat obvious lowering. Happy for
suggestions on a more clever way to lower this.
Now, what you might ask does this have to do with modules? Fun story. So
it turns out that libstdc++ actually uses __builtin_isinf_sign to
implement std::isinf when in C++98 mode, but only inside of a template.
So if we're lucky, and we never instantiate that, everything is good.
But once we try to instantiate that template function, we need this
builtin. All of my customers at least are using C++11 and so they never
hit this code path.
But what does that have to do with modules? Fun story. So it turns out
that with modules we actually observe a bunch of bugs in libstdc++ where
their <cmath> header clobbers things exposed by <math.h>. To fix these,
we have to provide global function definitions to replace the macros
that C99 would have used. And it turns out that ::isinf needs to be
implemented using the exact semantics used by the C++98 variant of
std::isinf. And so I started to fix this bug in libstdc++ and ceased to
be able to compile libstdc++ with Clang.
The yaks are legion.
llvm-svn: 232778
|
|
|
|
|
|
|
|
| |
Opt in Win64 to supporting sjlj lowering. We have the backend lowering,
so I think this was just an oversight because WinX86_64TargetCodeGenInfo
doesn't inherit from X86_64TargetCodeGenInfo.
llvm-svn: 231280
|
|
|
|
|
|
|
|
|
| |
mingw64's headers implement fabs by calling __builtin_fabs, so using the
library call results in an infinite loop. If the backend legalizes
@llvm.fabs as a call to fabs later, things should work out, as the crt
provides a definition.
llvm-svn: 221206
|
|
|
|
|
|
|
|
| |
AFAICT the semantics of frem match libm's fmod.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 218488
|
|
|
|
|
|
|
|
|
|
|
| |
Using the intrinsic allows the SelectionDAGBuilder to turn this call
into the FABS Node and also the intrinsic is something the vectorizer knows
how to vectorize.
This patch also sets the readnone attribute on this call, which should
enable additional optmizations.
llvm-svn: 217042
|
|
|
|
|
|
| |
tests fail.
llvm-svn: 188447
|
|
|
|
|
|
|
| |
GCC has always supported this on PowerPC and 4.8 supports it on all platforms,
so it's a good idea to expose it in clang too. LLVM supports this on all targets.
llvm-svn: 165362
|
|
|
|
|
|
| |
intrinsic.
llvm-svn: 161310
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
|
|
|
| |
llvm-svn: 105937
|
|
|
|
|
|
| |
LLVM backends support these yet.
llvm-svn: 104867
|
|
|
|
| |
llvm-svn: 104118
|
|
|
|
| |
llvm-svn: 103168
|
|
|
|
|
|
|
| |
float -> double (which happens because they are modelled as int(...)
functions), and add a testcase for isinf.
llvm-svn: 103167
|
|
|
|
|
|
|
| |
I'm reasonably sure my implementation is correct, but it would be nice if
someone could double-check.
llvm-svn: 97864
|
|
|
|
|
|
| |
Our testing framework can't deal with disabled targets yet.
llvm-svn: 97719
|
|
|
|
| |
llvm-svn: 97700
|
|
|
|
|
|
|
|
| |
evaluation of __builtin_nan*. Most of the work to make this work is in LLVM.
Fixes <rdar://problem/7696712> and part of PR 5255.
llvm-svn: 97383
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
|
|
|
|
| |
clang-cc when they do.
llvm-svn: 89070
|
|
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
|
|
|
| |
llvm-svn: 84183
|
|
|
|
| |
llvm-svn: 84167
|
|
|
|
| |
llvm-svn: 84160
|
|
|
|
| |
llvm-svn: 80655
|
|
|
|
| |
llvm-svn: 70794
|
|
|
|
|
|
| |
- PR3964.
llvm-svn: 68710
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
|
|
|
|
|
|
|
| |
functionality, fixing a crash on the attached testcase. Eliminate the
BuiltinFunctions cache, as it can contain dangling pointers. This fixes
a bunch of valgrind errors on test/CodeGen/builtins.c
llvm-svn: 67484
|
|
|
|
| |
llvm-svn: 65115
|
|
|
|
| |
llvm-svn: 57101
|
|
builtins).
llvm-svn: 55736
|