| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.
llvm-svn: 185568
|
|
|
|
| |
llvm-svn: 184862
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checked-arithmetic in c.
This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.
Tests/an update to Language Extensions is included as well.
rdar://13421498.
llvm-svn: 184497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
{add,sub} with carry for bytes.
I have had several people ask me about why this builtin was not available in
clang (since it seems like a logical conclusion). This patch implements said
builtins.
Relevant tests are included as well. I also updated the Clang language extension reference.
rdar://14192664.
llvm-svn: 184227
|
|
|
|
|
|
|
|
|
|
| |
Current gcc's produce an error if __clear_cache is anything but
__clear_cache(char *a, char *b);
It looks like we had just implemented a gcc bug that is now fixed.
llvm-svn: 181784
|
|
|
|
| |
llvm-svn: 181782
|
|
|
|
|
|
| |
There is no clangRewrite.a.
llvm-svn: 181781
|
|
|
|
|
|
|
| |
libgcc provides a __clear_cache intrinsic on AArch64, much like it
does on 32-bit ARM.
llvm-svn: 181111
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
| |
llvm-svn: 178331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
llvm-svn: 176656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
|
|
|
| |
llvm-svn: 172808
|
|
|
|
| |
llvm-svn: 172650
|
|
|
|
|
|
| |
We lower these into 2x chained usub.with.overflow intrinsics.
llvm-svn: 172476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ArrayRef<T>(X), X should not be temporary value. It could be rewritten more redundantly;
llvm::Type *XTy = X->getType();
ArrayRef<llvm::Type *> Ty(XTy);
llvm::Value *Callee = CGF.CGM.getIntrinsic(IntrinsicID, Ty);
Since it is safe if both XTy and Ty are temporary value in one statement, it could be shorten;
llvm::Value *Callee = CGF.CGM.getIntrinsic(IntrinsicID, ArrayRef<llvm::Type*>(X->getType()));
ArrayRef<T> has an implicit constructor to create uni-entry of T;
llvm::Value *Callee = CGF.CGM.getIntrinsic(IntrinsicID, X->getType());
MSVC-generated clang.exe crashed.
llvm-svn: 172352
|
|
|
|
|
|
|
| |
We lower all of these intrinsics into a 2x chained usage of
uadd.with.overflow.
llvm-svn: 172341
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR 14529 was opened because neither Clang or LLVM was expanding
calls to creal* or cimag* into instructions that just load the
respective complex field. After some discussion, it was not
considered realistic to do this in LLVM because of the platform
specific way complex types are expanded. Thus a way to solve
this in Clang was pursued. GCC does a similar expansion.
This patch adds the feature to Clang by making the creal* and
cimag* functions library builtins and modifying the builtin code
generator to look for the new builtin types.
llvm-svn: 170455
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
| |
llvm-svn: 169114
|
|
|
|
|
|
|
| |
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
|
|
|
|
| |
llvm-svn: 166684
|
|
|
|
|
|
|
| |
Eli discovered that __noop's sema behavior also needs some love. I filed
PR14081 for that and intend to improve it.
llvm-svn: 165886
|
|
|
|
|
|
| |
of the checks fails.
llvm-svn: 165536
|
|
|
|
| |
llvm-svn: 165395
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 164904
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
llvm-svn: 164769
|
|
|
|
| |
llvm-svn: 164766
|
|
|
|
| |
llvm-svn: 164660
|
|
|
|
|
|
|
|
|
|
|
| |
The expression based expansion too often results in IR level optimizations
splitting the intermediate values into separate basic blocks, preventing
the formation of the VBSL instruction as the code author intended. In
particular, LICM would often hoist part of the computation out of a loop.
rdar://11011471
llvm-svn: 164342
|
|
|
|
| |
llvm-svn: 164341
|
|
|
|
|
|
|
|
|
| |
the trap BB out of the individual checks and into a common function, to prepare
for making this code call into a runtime library. Rename the existing EmitCheck
to EmitTypeCheck to clarify it and to move it out of the way of the new
EmitCheck.
llvm-svn: 163451
|
|
|
|
|
|
| |
non-pointer types with a pointer representation correctly. PR13660.
llvm-svn: 162862
|
|
|
|
| |
llvm-svn: 162440
|
|
|
|
|
|
|
| |
of a pointer for builtin emission, instead of just depending on the type of the
pointee. <rdar://problem/11314941>.
llvm-svn: 162425
|
|
|
|
|
|
| |
calls. // rdar://8315199
llvm-svn: 161891
|
|
|
|
|
|
|
|
|
| |
The backend has to legalize i64 types by splitting them into two 32-bit pieces,
which leads to poor quality code. If we produce code for these intrinsics that
uses one-element vector types, which can live in Neon vector registers without
getting split up, then the generated code is much better. Radar 11998303.
llvm-svn: 161879
|
|
|
|
|
|
| |
intrinsic.
llvm-svn: 161310
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsics. The second instruction(s) to be handled are the vector versions
of count set bits (ctpop).
The changes here are to clang so that it generates a target independent
vector ctpop when it sees an ARM dependent vector bits set count. The changes
in llvm are to match the target independent vector ctpop and in
VMCore/AutoUpgrade.cpp to update any existing bc files containing ARM
dependent vector pop counts with target-independent ctpops. There are also
changes to an existing test case in llvm for ARM vector count instructions and
to a test for the bitcode upgrade.
<rdar://problem/11892519>
There is deliberately no test for the change to clang, as so far as I know, no
consensus has been reached regarding how to test neon instructions in clang;
q.v. <rdar://problem/8762292>
llvm-svn: 160409
|
|
|
|
| |
llvm-svn: 160353
|
|
|
|
|
|
|
| |
This function has two versions. The first one is used for a register operand.
The second one is used for an immediate number.
llvm-svn: 160308
|
|
|
|
| |
llvm-svn: 160220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsics with target-indepdent intrinsics. The first instruction(s) to be
handled are the vector versions of count leading zeros (ctlz).
The changes here are to clang so that it generates a target independent
vector ctlz when it sees an ARM dependent vector ctlz. The changes in llvm
are to match the target independent vector ctlz and in VMCore/AutoUpgrade.cpp
to update any existing bc files containing ARM dependent vector ctlzs with
target-independent ctlzs. There are also changes to an existing test case in
llvm for ARM vector count instructions and a new test for the bitcode upgrade.
<rdar://problem/11831778>
There is deliberately no test for the change to clang, as so far as I know, no
consensus has been reached regarding how to test neon instructions in clang;
q.v. <rdar://problem/8762292>
llvm-svn: 160201
|
|
|
|
| |
llvm-svn: 160118
|
|
|
|
|
|
|
|
| |
in the ABI arrangement, and leave a hook behind so that we can easily
tweak CCs on platforms that use different CCs by default for C++
instance methods.
llvm-svn: 159894
|
|
|
|
|
|
|
|
| |
The tablegen'd code does the same thing without this egregious duplication.
In my limited testing everything seems to work, however there can be
differences if the clang and llvm builtin definitions don't match.
llvm-svn: 159371
|
|
|
|
|
|
|
|
| |
handwritten emitter.
The generated code uncovered an invalid prototype for __builtin_mips_shilo, fix it along the way.
llvm-svn: 159368
|