| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
|
| |
|
|
|
|
|
|
|
| |
As of cl.exe version 18, the special layout rules for structs with
alignment 16 or greater has been dropped. This patch drops the behavior
from clang. This patch also updates the lit tests to reflect the
change.
llvm-svn: 204674
|
| |
|
|
| |
llvm-svn: 204673
|
| |
|
|
|
|
|
|
|
| |
This is used to avoid relocations in the dwo file by allowing
DW_AT_ranges specified in debug_info.dwo to be relative to this base
address. (r204667 implements the base-relative DW_AT_ranges side of
this)
llvm-svn: 204672
|
| |
|
|
| |
llvm-svn: 204671
|
| |
|
|
|
|
|
|
| |
plain old CHECKs.
Follow-up to r204633.
llvm-svn: 204670
|
| |
|
|
|
|
|
| |
This is a testcase follow-up to r204627.
(see also r204614 for CALL_ELF usage).
llvm-svn: 204669
|
| |
|
|
|
|
|
|
| |
This removes the debug_ranges relocations from debug_info.dwo (but
doesn't implement the DW_AT_GNU_ranges_base which is also necessary for
correct functioning)
llvm-svn: 204668
|
| |
|
|
| |
llvm-svn: 204667
|
| |
|
|
|
|
|
|
|
|
| |
v2:
- Use a hexadecimal constant.
v3:
- Use a hexadecimal constant in floating-point notation.
llvm-svn: 204666
|
| |
|
|
| |
llvm-svn: 204665
|
| |
|
|
|
|
|
| |
Having these popping up every time you use -debug is really
irritating.
llvm-svn: 204664
|
| |
|
|
| |
llvm-svn: 204663
|
| |
|
|
|
|
|
| |
Check the register class of each operand individually
to avoid an extra copy to a vgpr.
llvm-svn: 204662
|
| |
|
|
|
|
|
| |
No longer asserts, but now you get moves loading legal immediates
into the split 32-bit operations.
llvm-svn: 204661
|
| |
|
|
|
|
|
|
| |
Try to match scalar and first like the other instructions.
Expand 64-bit ands to a pair of 32-bit ands since that is not
available on the VALU.
llvm-svn: 204660
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
User.cpp
never returns, which is true by design.
Initially assumed that the reason is llvm_unreachable being dependent on NDEBUG.
However, even if llvm_unreachable is replaced by __assume(false), VC still warns in
Release modes but not in Debug modes...
The real reason turned out to be optimization flags.
With /Od in Debug modes the warning is not issued whereas with /O1 it is.
I could not find any documentation to this effect, but it is reproducable:
Try compiling http://msdn.microsoft.com/en-us/library/khwfyc5d(v=vs.90).aspx
with /O1 and then with /Od.
llvm-svn: 204659
|
| |
|
|
| |
llvm-svn: 204658
|
| |
|
|
|
|
| |
as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))
llvm-svn: 204657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make vector clock operations O(1) for several important classes of use cases.
See comments for details.
Below are stats from a large server app, 77% of all clock operations are handled as O(1).
Clock acquire : 25983645
empty clock : 6288080
fast from release-store : 14917504
contains my tid : 4515743
repeated (fast) : 2141428
full (slow) : 2636633
acquired something : 1426863
Clock release : 2544216
resize : 6241
fast1 : 197693
fast2 : 1016293
fast3 : 2007
full (slow) : 1797488
was acquired : 709227
clear tail : 1
last overflow : 0
Clock release store : 3446946
resize : 200516
fast : 469265
slow : 2977681
clear tail : 0
Clock acquire-release : 820028
llvm-svn: 204656
|
| |
|
|
| |
llvm-svn: 204655
|
| |
|
|
| |
llvm-svn: 204654
|
| |
|
|
|
|
|
|
|
|
|
|
| |
required.
Also mark #2104 as complete. Leave the implementation in libc++ as noexcept, since
implementations are allowed to add noexcept to non-virtual calls. If we throw from
unique_lock& operator=(unique_lock&& u), then that means the preconditions were violated,
and calling terminate() (as a result of throwing from a noexcept function) is as
good example of undefined behavior as any other.
llvm-svn: 204653
|
| |
|
|
|
|
|
|
|
|
| |
FreeBSD recently updated to Clang 3.4 and the TestFormatters test case
started failing as it omits the C1 complete object constructor when not
needed.
llvm.org/pr19011
llvm-svn: 204652
|
| |
|
|
| |
llvm-svn: 204651
|
| |
|
|
|
|
| |
a promise to add more information later.
llvm-svn: 204635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a first step towards real little-endian code generation, this patch
changes the PowerPC MC layer to actually generate little-endian object
files. This involves passing the little-endian flag through the various
layers, including down to createELFObjectWriter so we actually get basic
little-endian ELF objects, emitting instructions in little-endian order,
and handling fixups and relocations as appropriate for little-endian.
The bulk of the patch is to update most test cases in test/MC/PowerPC
to verify both big- and little-endian encodings. (The only test cases
*not* updated are those that create actual big-endian ABI code, like
the TLS tests.)
Note that while the object files are now little-endian, the generated
code itself is not yet updated, in particular, it still does not adhere
to the ELFv2 ABI.
llvm-svn: 204634
|
| |
|
|
|
|
|
| |
This was failing on an internal branch where the order was different for
some reason. <rdar://problem/16407581>
llvm-svn: 204633
|
| |
|
|
| |
llvm-svn: 204632
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Those patterns are used when the load cannot be folded into the related broadcast
during the select phase.
This happens when the load gets additional uses that were not anticipated during
the previous lowering phases (constant vector to constant load, then constant
load reused) or when selection DAG is not able to prove that folding the load
will not create a cycle in the DAG.
<rdar://problem/16074331>
llvm-svn: 204631
|
| |
|
|
| |
llvm-svn: 204630
|
| |
|
|
|
|
|
|
|
|
| |
Previously we would print an error message on machines where the only VS
version we find is 2013, even though we successfully install the integration
files for it.
Also, we shouldn't have two END labels.
llvm-svn: 204629
|
| |
|
|
|
|
| |
It is to avoid build error when gcc defines i386.
llvm-svn: 204628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additional clarification from Uli for the background on _CALL_ELF:
"Historically GCC has provided various _CALL_... predefines depending on the
ABI currently being compiled for. (_CALL_SYSV,_CALL_AIXDESC, _CALL_DARWIN )
When we needed a new define for the current ABI, we decided on using _CALL_ELF
since the official name of the ABI is the OpenPower ElfV2 ABI, with the
current Linux ABI retro-actively being renamed the ELFv1 ABI
and so we decided on using _CALL_ELF to identify the Linux (+BSD etc.) ELF ABI,
with _CALL_ELF=1 for the v1 ABI and _CALL_ELF=2 for the v2 ABI.
(Note that this matches the gcc compiler switch -mabi=elfv1 vs. -mabi=elfv2)."
In code, a (_CALL_ELF==2) check will indicate when the ELFv2 ABI is
to be used. This is the desired default for the PPC64 LE target.
llvm-svn: 204627
|
| |
|
|
|
|
|
|
|
|
| |
the PPC64LE target. Specifically:
(assembler) adds/uses -mppc64 -mlittle-endian
(linker) adds/uses elf64lppc
Testcase included.
llvm-svn: 204626
|
| |
|
|
|
|
| |
Make sure such IR gets properly lowered to PTX.
llvm-svn: 204624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be observed with the old testcase of CodeGen/X86/pr12312.ll:
47c47
< vorps %ymm0, %ymm1, %ymm0
---
> vorps %ymm1, %ymm0, %ymm0
97c97
< vorps %ymm1, %ymm0, %ymm0
---
> vorps %ymm0, %ymm1, %ymm0
The vector VecIns is populated with all the values from VecInMap. This is done
while iterating VecInMap. VecInMap uses a hash of pointer values so the
resulting order can vary depending on the memory layout.
The fix is to populate the vector VecIns earlier as VecInMap is populated.
This is done in DAG traversal order.
Fixes <rdar://problem/16398806>
llvm-svn: 204623
|
| |
|
|
|
|
| |
safe and also fixed a missed member initialization on the copy contractor and also makes the assignment operator safer.
llvm-svn: 204622
|
| |
|
|
|
|
|
|
|
|
| |
Summary:
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3158
llvm-svn: 204621
|
| |
|
|
|
|
|
| |
This pass is a historic remnant and actually causes less efficient code to be
generated in some cases.
llvm-svn: 204620
|
| |
|
|
| |
llvm-svn: 204619
|
| |
|
|
| |
llvm-svn: 204618
|
| |
|
|
|
|
|
| |
This type promotion is replacing a Tablegen pattern and it is already
covered by existing tests.
llvm-svn: 204617
|
| |
|
|
|
|
|
|
| |
And vice-versa, as long as the types are the same width.
There are a few R600 tests that will cover this.
llvm-svn: 204616
|
| |
|
|
|
|
| |
Each GPU family now has its own file.
llvm-svn: 204615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[PPC64LE] ELFv2 ABI updates for the .opd section
The PPC64 Little Endian (PPC64LE) target supports the ELFv2 ABI, and as
such, does not have a ".opd" section. This is keyed off a _CALL_ELF=2
macro check.
The CALL_ELF check is not clearly documented at this time. The basis
for usage in this patch is from the gcc thread here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01144.html
> Adding comment from Uli:
Looks good to me. I think the old-style JIT doesn't really work
anyway for 64-bit, but at least with this patch LLVM will compile
and link again on a ppc64le host ...
llvm-svn: 204614
|
| |
|
|
|
|
|
|
|
|
| |
Update DataLayout/DescriptionString for ppc64le
Similar LLVM change made in r203664
Testcase included.
llvm-svn: 204613
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These expressions already worked but weren't tested.
Patch by Robert N. M. Watson and David Chisnall (it was originally two patches)
Their work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3156
llvm-svn: 204612
|
| |
|
|
|
|
|
|
|
|
| |
Summary:
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3155
llvm-svn: 204611
|
| |
|
|
|
|
| |
buildbots seem to OOM with that many threads
llvm-svn: 204610
|