| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Merge vrshr_n_v and vqshlu_n_v with ARM.
Remove FIXME comments for others as they can't actually be shared.
NFC.
Differential Revision: http://reviews.llvm.org/D4697
llvm-svn: 214173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This broke the following gdb tests:
gdb.base__annota1.exp
gdb.base__consecutive.exp
gdb.python__py-symtab.exp
gdb.reverse__consecutive-precsave.exp
gdb.reverse__consecutive-reverse.exp
I will look into this.
This reverts commit 214162.
llvm-svn: 214163
|
| |
|
|
|
|
|
|
|
| |
This allows us to give more precise diagnostics.
Diego kindly tested the impact on debug info size: "The increase on average
debug sizes is 0.1%. The total file size increase is ~0%."
llvm-svn: 214162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't nearly as elaborate as the GCC inline asm which emits an
array of source locations, but it's very, very hard to trigger backend
diagnostics in MS inline asm because we parse it up front with good
source information, unlike GCC inline asm.
Currently I can trigger a "inline assembly requires more registers than
available" diagnostic with this code:
void foo();
void bar() {
__asm pusha
__asm call foo
__asm popa
}
However, if I committed that as a test case, I would have to remove it
once I fix PR20052.
llvm-svn: 214141
|
| |
|
|
|
|
|
| |
This is the last patch to unique the type array of a subroutine type.
This is the paired commit with llvm r214132.
llvm-svn: 214133
|
| |
|
|
|
|
| |
This is the paired commit with llvm r214112.
llvm-svn: 214113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This moves some memptr specific code into the generic thunk emission
codepath.
Fixes PR20053.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D4613
llvm-svn: 214004
|
| |
|
|
| |
llvm-svn: 214003
|
| |
|
|
|
|
|
|
|
| |
llvm revision 210639 renamed the -global-merge backend option to
-enable-global-merge. This change simply updates clang to match that.
Patch by Steven Wu!
llvm-svn: 213993
|
| |
|
|
|
|
|
|
|
| |
Previously we were building up the inalloca struct in the usual pattern
of return type followed by arguments. However, on Windows, 'this'
always precedes the 'sret' parameter, so we need to insert it into the
struct first as a special case.
llvm-svn: 213990
|
| |
|
|
|
|
|
|
| |
The target method of the thunk will perform the cleanup. This can't be
tested in 32-bit x86 yet because passing something by value would create
an inalloca, and we refuse to generate broken code for that.
llvm-svn: 213976
|
| |
|
|
| |
llvm-svn: 213927
|
| |
|
|
|
|
|
| |
While -fno-rtti-data would correctly avoid referencing the RTTI complete
object locator in the VFTable itself, it would emit them anyway.
llvm-svn: 213841
|
| |
|
|
|
|
| |
new form using the string "full".
llvm-svn: 213771
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
|
| |
|
|
| |
llvm-svn: 213639
|
| |
|
|
| |
llvm-svn: 213616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
llvm-svn: 213593
|
| |
|
|
| |
llvm-svn: 213587
|
| |
|
|
|
|
|
|
|
| |
objects."
This commit did break the sanitizer-x86 bot. Revert it while
investigating.
llvm-svn: 213579
|
| |
|
|
|
|
| |
This will give more information to the optimizers so that they can reuse stack slots.
llvm-svn: 213576
|
| |
|
|
| |
llvm-svn: 213512
|
| |
|
|
| |
llvm-svn: 213510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to enabling ELFv2 homogeneous aggregate handling,
LLVM support to pass array types directly also enables a performance
enhancement. We can now pass (non-homogeneous) aggregates that fit
fully in registers as direct integer arrays, using an element type
to encode the alignment requirement (that would otherwise go to the
"byval align" field).
This is preferable since "byval" forces the back-end to write the
aggregate out to the stack, even if it could be passed fully in
registers. This is particularly annoying on ELFv2, if there is
no parameter save area available, since we then need to allocate
space on the callee's stack just to hold those aggregates.
Note that to implement this optimization, this patch does not attempt
to fully anticipate register allocation rules as (defined in the
ABI and) implemented in the back-end. Instead, the patch is simply
passing *any* aggregate passed by value using the array mechanism
if its size is up to 64 bytes. This means that some of those will
end up being passed in stack slots anyway, but the generated code
shouldn't be any worse either. (*Large* aggregates remain passed
using "byval" to enable optimized copying via memcpy etc.)
llvm-svn: 213495
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements clang support for the PowerPC ELFv2 ABI.
Together with a series of companion patches in LLVM, this makes
clang/LLVM fully usable on powerpc64le-linux.
Most of the ELFv2 ABI changes are fully implemented on the LLVM side.
On the clang side, we only need to implement some changes in how
aggregate types are passed by value. Specifically, we need to:
- pass (and return) "homogeneous" floating-point or vector aggregates in
FPRs and VRs (this is similar to the ARM homogeneous aggregate ABI)
- return aggregates of up to 16 bytes in one or two GPRs
The second piece is trivial to implement in any case. To implement
the first piece, this patch makes use of infrastructure recently
enabled in the LLVM PowerPC back-end to support passing array types
directly, where the array element type encodes properties needed to
handle homogeneous aggregates correctly.
Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
With this support in place, the clang part simply needs to *detect*
whether an aggregate type implements a float / vector homogeneous
aggregate as defined by the ELFv2 ABI, and if so, pass/return it
as array type using the appropriate float / vector element type.
llvm-svn: 213494
|
| |
|
|
|
|
|
| |
The enum is part of ArrayType, so there is no functional change, but comparing
to ArrayType::Static for non-VLAs makes more sense.
llvm-svn: 213446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C99, an array parameter declarator might have the form:
direct-declarator '[' 'static' type-qual-list[opt] assign-expr ']'
where the static keyword indicates that the caller will always provide a
pointer to the beginning of an array with at least the number of elements
specified by the assignment expression. For constant sizes, we can use the
new dereferenceable attribute to pass this information to the optimizer. For
VLAs, we don't know the size, but (for addrspace(0)) do know that the pointer
must be nonnull (and so we can use the nonnull attribute).
llvm-svn: 213444
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Thoroughly check for a pointer dereference which yields a glvalue. Look
through casts, comma operators, conditional operators, paren
expressions, etc.
This was originally D4416.
Differential Revision: http://reviews.llvm.org/D4592
llvm-svn: 213434
|
| |
|
|
|
|
| |
CGBuilder doesn't name instructions with Name. We should use Inst::setName() to name an instruction explicitly here.
llvm-svn: 213431
|
| |
|
|
| |
llvm-svn: 213415
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r213401, r213402, r213403, and r213404.
I accidently committed these changes instead of updating the
differential.
llvm-svn: 213405
|
| |
|
|
| |
llvm-svn: 213404
|
| |
|
|
| |
llvm-svn: 213403
|
| |
|
|
| |
llvm-svn: 213402
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Thoroughly check for a pointer dereference which yields a glvalue. Look
through casts, comma operators, conditional operators, paren
expressions, etc.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4416
llvm-svn: 213401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang uses a diagnostic handler to grab diagnostic messages so it can print them
with the line of source code they refer to. This patch extends this to handle
optimization failures that were added to llvm to produce a warning when
loop vectorization is explicitly specified (using a pragma clang loop directive)
but fails.
Update renames warning flag name to avoid indicating the flag's severity and
adds a test.
Reviewed by Alp Toker
llvm-svn: 213400
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise -fsanitize=vptr causes the program to crash when it downcasts
a null pointer.
Reviewed in http://reviews.llvm.org/D4412.
Patch by Byoungyoung Lee!
llvm-svn: 213393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
llvm.asan.globals metadata, effectively "blacklisting" them. This can
dramatically decrease the data section in binaries built with UBSan+ASan,
as UBSan tends to create a lot of handlers, and ASan instrumentation
increases the global size to at least 64 bytes.
Test Plan: clang regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, byoungyoung, kcc
Differential Revision: http://reviews.llvm.org/D4575
llvm-svn: 213392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.
Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.
llvm-svn: 213386
|
| |
|
|
|
|
|
|
|
| |
objects."
This reverts commit dbf785a6432f78a8ec229665876647c4cc610d3d, while I qm
investigating a buildbot failure.
llvm-svn: 213380
|
| |
|
|
|
|
| |
This will give more information to the optimizers so that they can reuse stack slots.
llvm-svn: 213379
|
| |
|
|
| |
llvm-svn: 213363
|
| |
|
|
| |
llvm-svn: 213360
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r211898 introduced a regression where a large struct, which would
normally be passed ByVal, was causing padding to be inserted to
prevent the backend from using some GPRs, in order to follow the
AAPCS. However, the type of the argument was not being set correctly,
so the backend cannot align 8-byte aligned struct types on the stack.
The fix is to not insert the padding arguments when the argument is
being passed ByVal.
llvm-svn: 213359
|
| |
|
|
| |
llvm-svn: 213355
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
|
| |
|
|
|
|
|
|
|
| |
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
members (PR20140)
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
|
| |
|
|
|
|
|
|
|
|
| |
This is used to mark the instructions emitted by Clang to implement
variety of UBSan checks. Generally, we don't want to instrument these
instructions with another sanitizers (like ASan).
Reviewed in http://reviews.llvm.org/D4544
llvm-svn: 213291
|