| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Create a helper function to construct a value for the ARM hint intrinsic
rather than inling the construction. In order to avoid the use of the sentinel
value, inline the use of intrinsic instruction retrieval. NFC.
llvm-svn: 223338
|
| |
|
|
|
|
| |
Use the same approach as _umul128, but just return the high half.
llvm-svn: 223316
|
| |
|
|
| |
llvm-svn: 223311
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
llvm-svn: 223271
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of
the data being stored rather than on the pointer being stored to.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D5916
llvm-svn: 223267
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D6505
llvm-svn: 223248
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
return (a > b
// comment1
// comment2
|| c);
After:
return (a > b
// comment1
// comment2
|| c);
llvm-svn: 223234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uncovered by a Java test case:
Before:
public some.package.Type someFunction( // comment
int parameter) {}
After:
public some.package.Type someFunction( // comment
int parameter) {}
llvm-svn: 223228
|
| |
|
|
| |
llvm-svn: 223225
|
| |
|
|
|
|
| |
ParsePostfixExpressionSuffix.
llvm-svn: 223209
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As the semantics of prefix data has changed. See D6454.
Patch by Ben Gamari!
Test Plan: Testsuite
Differential Revision: http://reviews.llvm.org/D6489
llvm-svn: 223190
|
| |
|
|
|
|
|
| |
r142020 added support for has_feature(cxx_alignas). This does the same for
alignof.
llvm-svn: 223186
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this program:
struct A {
virtual void operator-() { printf("base\n"); }
};
struct B final : public A {
virtual void operator-() override { printf("derived\n"); }
};
int main() {
B* b = new B;
-static_cast<A&>(*b);
}
Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable. Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.
For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.
This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.
This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.
(This adjustment for virtual operator calls seems still wrong with the MS ABI.)
llvm-svn: 223185
|
| |
|
|
|
|
| |
that contained side effects.
llvm-svn: 223184
|
| |
|
|
| |
llvm-svn: 223179
|
| |
|
|
| |
llvm-svn: 223177
|
| |
|
|
| |
llvm-svn: 223176
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement _umul128; it provides the high and low halves of a 128-bit
multiply. We can simply use our __int128 arithmetic to implement this,
we generate great code for it:
movq %rdx, %rax
mulq %rcx
movq %rdx, (%r8)
retq
Differential Revision: http://reviews.llvm.org/D6486
llvm-svn: 223175
|
| |
|
|
|
|
|
|
| |
There's no need to use different names for the local variables than we
use in the profile itself, and it's a bit simpler and easier to debug
if we're consistent.
llvm-svn: 223173
|
| |
|
|
|
|
|
|
| |
It doesn't make much sense to have std::unique_ptrs of std::string and
std::vector. Avoid some useless indirection by using these types
directly.
llvm-svn: 223166
|
| |
|
|
|
|
|
| |
Also have CorrectDelayedTyposInExpr check that the Expr* isn't null
before trying to access its members. Fixes PR21679.
llvm-svn: 223162
|
| |
|
|
| |
llvm-svn: 223149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In particular, remove the defaults and reorder fields so it matches the result of DataLayout::getStringDescription().
Change by David Neto.
Reviewers: dschuff, sdt
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6482
llvm-svn: 223140
|
| |
|
|
|
|
|
|
| |
expressions. It fixes crash when mangling name for block's helper
function used inside a constructor/destructor.
rdar://19065361.
llvm-svn: 223136
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM ABI specifies that all the libcalls use soft FP ABI
(even hard FP binaries). These days clang emits _mulsc3 / _muldc3
calls with default (C) calling convention which would be translated
into AAPCS_VFP LLVM calling and thus the result of complex
multiplication will be bogus.
Introduce a way for a target to specify explicitly calling
convention for libcalls. Right now this is temporary correctness
fix. Ultimately, we'll end with intrinsic for complex
multiplication and all calling convention decisions for libcalls
will be put into backend.
llvm-svn: 223123
|
| |
|
|
| |
llvm-svn: 223120
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
llvm-svn: 223117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
== aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
* bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
&& aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
* aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> ccccccccccccccccccccccccccccccccccccccccc;
After:
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
== aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
* bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
&& aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
* aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> ccccccccccccccccccccccccccccccccccccccccc;
Not particularly pretty, but can probably help to uncover bugs. And if this
bugs somebody, parentheses can help.
llvm-svn: 223111
|
| |
|
|
| |
llvm-svn: 223105
|
| |
|
|
|
|
|
|
|
|
| |
I added this check a while back but then made a note to myself that it
should be completely unnecessary since iOS always uses PIC code-gen for
aarch64. Since I could never come up with any reason why it would be
necessary, I'm just going to remove it and we'll see if anything breaks.
rdar://problem/13627985
llvm-svn: 223097
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
|
| |
|
|
| |
llvm-svn: 223090
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Using lld on Windows requires calling link-lld.exe instead of
lld.exe. This patch puts this knowledge into clang so that when
using the GCC style clang driver, it can properly delegate to
lld.
Differential Revision: http://reviews.llvm.org/D6428
Reviewed by: Reid Kleckner, Rui Ueyama
llvm-svn: 223086
|
| |
|
|
|
|
|
|
|
|
|
| |
Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an integer
literal zero and fires off a warning. Only CodeGen currently knows that
it promotes integer literal zeroes in this context to pointer size on
Windows. I didn't want to teach -Wsentinel about that compatibility
hack. Therefore, I'm migrating to C++11 nullptr.
llvm-svn: 223079
|
| |
|
|
|
|
| |
fallthrough happened to do the right thing in both cases.
llvm-svn: 223064
|
| |
|
|
| |
llvm-svn: 223046
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Speed up the variadic matchers by removing one indirect call.
Making the function pointer a template arguments allows the compiler to
inline the call instead of doing an runtime call by pointer.
Also, optimize the allOf() case to avoid redundant kind checks.
This speeds up our clang-tidy benchmark by ~2%
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D6424
llvm-svn: 223029
|
| |
|
|
|
|
| |
No functional changes, only code improvements.
llvm-svn: 223010
|
| |
|
|
|
|
| |
Revert r222993 while I investigate some MemorySanitizer failures.
llvm-svn: 222995
|
| |
|
|
|
|
|
|
|
| |
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
llvm-svn: 222993
|
| |
|
|
| |
llvm-svn: 222964
|
| |
|
|
|
|
|
|
| |
We didn't consider types like ObjCSel as a substitution candidate.
This fixes PR21688.
llvm-svn: 222941
|
| |
|
|
|
|
|
|
|
| |
Add neon-vfpv3 to allow specifying both at the same time. This is not an
option that GCC supports, but follows the same track and should be
non-controversial.
Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658
llvm-svn: 222933
|
| |
|
|
|
|
|
| |
This enables user to architecturally specify ARMv7A + VFPv4 + NEON.
Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f
llvm-svn: 222932
|
| |
|
|
|
|
| |
According to OpenMP standard, Section 2.12.6, atomic Construct, '#pragma omp atomic write' is allowed to be used only for expression statements of form 'x = expr;', where x is a lvalue expression and expr is an expression with scalar type. Patch adds checks for it.
llvm-svn: 222913
|
| |
|
|
|
|
|
|
|
|
|
| |
This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.
Reviewed by Aaron Ballman.
llvm-svn: 222906
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that LLVM can count the registers needed to implement AAPCS rules, we don't
need to duplicate that logic here. This means we can drop the explicit padding
and also use more natural types in many cases (e.g. "struct { float arr[3]; }"
used to end up as "[2 x double]" to avoid holes on the stack.
The one wrinkle is that AAPCS va_arg was also using the register counting
machinery. But the local replacement isn't too bad.
llvm-svn: 222904
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
var someVariable =
function(x) { return x.zIsTooLongForOneLineWithTheDeclarationLine(); };
After:
var someVariable = function(x) {
return x.zIsTooLongForOneLineWithTheDeclarationLine();
};
llvm-svn: 222893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
var obj = {
fooooooooo:
function(x) { return x.zIsTooLongForOneLineWithTheDeclarationLine(); }
};
After:
var obj = {
fooooooooo: function(x) {
return x.zIsTooLongForOneLineWithTheDeclarationLine();
}
};
llvm-svn: 222892
|