Age | Commit message (Collapse) | Author |
|
Patch by Stephen Lin!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We lower these into 2x chained usub.with.overflow intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172352 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We lower all of these intrinsics into a 2x chained usage of
uadd.with.overflow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169114 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Eli discovered that __noop's sema behavior also needs some love. I filed
PR14081 for that and intend to improve it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the checks fails.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165536 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165395 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164769 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163451 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-pointer types with a pointer representation correctly. PR13660.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162862 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a pointer for builtin emission, instead of just depending on the type of the
pointee. <rdar://problem/11314941>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
calls. // rdar://8315199
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161879 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This function has two versions. The first one is used for a register operand.
The second one is used for an immediate number.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160220 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160201 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160118 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159371 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handwritten emitter.
The generated code uncovered an invalid prototype for __builtin_mips_shilo, fix it along the way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch was reviewed in the llvm-commits list by Jim Grosbach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer, but such folding encounters side-effects, ignore the side-effects
rather than performing them at runtime: CodeGen generates wrong code for
__builtin_object_size in that case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM r157255)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157256 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
add a test for -fbounds-checking code generation
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
previously done for SSE builtins.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156296 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
test suite failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155371 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155363 91177308-0d34-0410-b5e6-96231b3b80d8
|