| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This fixes various symbolization test failures for me when I build with a
hermetic VS2015 without having run the 2015 installer.
http://reviews.llvm.org/D18707
llvm-svn: 265193
|
| |
|
|
| |
llvm-svn: 265192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These function can be dropped by the compiler if they are no longer
referenced in the current module. However there is a change that
another module is still referencing them because of the import.
Multiple solutions can be used:
- Always import LinkOnce when a caller is imported. This ensure that
every module with a call to a LinkOnce has the definition and will
be able to emit it if it emits the call.
- Turn the LinkOnce into Weak, so that it is always emitted.
- Turn all LinkOnce into available_externally and come back after all
modules are codegen'ed to emit only one copy of the linkonce, when
there is still a reference to it.
This patch implement the second option, with am optimization that
only *one* module will turn the LinkOnce into Weak, while the others
will turn it into available_externally, so that there is exactly one
copy emitted for the whole compilation.
http://reviews.llvm.org/D18346
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265190
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.
This commit does not include any target-specific change. The target-specific
optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
llvm-svn: 265189
|
| |
|
|
|
|
| |
float2double
llvm-svn: 265186
|
| |
|
|
| |
llvm-svn: 265185
|
| |
|
|
| |
llvm-svn: 265184
|
| |
|
|
| |
llvm-svn: 265183
|
| |
|
|
| |
llvm-svn: 265182
|
| |
|
|
| |
llvm-svn: 265180
|
| |
|
|
| |
llvm-svn: 265179
|
| |
|
|
|
|
|
|
|
|
|
| |
ThreadModel::Single is already handled already by ARMPassConfig adding
LowerAtomicPass to the pass list, which lowers all atomics to non-atomic
ops and deletes fences.
So by the time we get to ISel, there's no atomic fences left, so they
don't need special handling.
llvm-svn: 265178
|
| |
|
|
|
|
| |
Should fix modules build.
llvm-svn: 265176
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18705
llvm-svn: 265174
|
| |
|
|
| |
llvm-svn: 265173
|
| |
|
|
|
|
|
|
|
| |
Was there really no other way to splat a byte in SSE2?
punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
pshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
pshufd {{.*#+}} xmm0 = xmm0[0,0,1,1]
llvm-svn: 265172
|
| |
|
|
| |
llvm-svn: 265171
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement BUFFER_ATOMIC_CMPSWAP{,_X2} instructions on all GCN targets, and FLAT_ATOMIC_CMPSWAP{,_X2} on CI+.
32-bit instruction variants tested manually on Kabini and Bonaire. Tests and parts of code provided by Jan Veselý.
Patch by: Vedran Miletić
Reviewers: arsenm, tstellarAMD, nhaehnle
Subscribers: jvesely, scchan, kanarayan, arsenm
Differential Revision: http://reviews.llvm.org/D17280
llvm-svn: 265170
|
| |
|
|
|
|
| |
Added SSE + AVX1 tests as well as AVX2
llvm-svn: 265169
|
| |
|
|
| |
llvm-svn: 265168
|
| |
|
|
|
|
|
|
| |
Note however that this is identical to the existing SSE2 run.
What we really want is yet another run for an SSE2 machine that
also has fast unaligned 16-byte accesses.
llvm-svn: 265167
|
| |
|
|
| |
llvm-svn: 265164
|
| |
|
|
|
|
| |
Replaced lots of dodgy greps with actual codegen
llvm-svn: 265163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to http://reviews.llvm.org/D18566 and http://reviews.llvm.org/D18676 -
where we noticed that an intermediate splat was being generated for memsets of
non-zero chars.
That was because we told getMemsetStores() to use a 32-bit vector element type,
and it happily obliged by producing that constant using an integer multiply.
The 16-byte test that was added in D18566 is now equivalent for AVX1 and AVX2
(no splats, just a vector load), but we have PR27141 to track that splat difference.
Note that the SSE1 path is not changed in this patch. That can be a follow-up.
This patch should resolve PR27100.
llvm-svn: 265161
|
| |
|
|
| |
llvm-svn: 265160
|
| |
|
|
|
|
| |
A catchswitch is a terminator, instructions cannot be inserted after it.
llvm-svn: 265158
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A catchswitch cannot be preceded by another instruction in the same
basic block (other than a PHI node).
Instead, insert the extract element right after the materialization of
the vectorized value. This isn't optimal but is a reasonable compromise
given the constraints of WinEH.
This fixes PR27163.
llvm-svn: 265157
|
| |
|
|
|
|
|
|
|
| |
Refactor the code that gets and creates PGOFuncName meta data so that it can be
used in clang's value profile annotation.
Differential Revision: http://reviews.llvm.org/D18623
llvm-svn: 265149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to D18566 - where we noticed that an intermediate splat was being
generated for memsets of non-zero chars.
That was because we told getMemsetStores() to use a 32-bit vector element type,
and it happily obliged by producing that constant using an integer multiply.
The tests that were added in the last patch are now equivalent for AVX1 and AVX2
(no splats, just a vector load), but we have PR27141 to track that splat difference.
In the new tests, the splat via shuffling looks ok to me, but there might be some
room for improvement depending on uarch there.
Note that the SSE1/2 paths are not changed in this patch. That can be a follow-up.
This patch should resolve PR27100.
Differential Revision: http://reviews.llvm.org/D18676
llvm-svn: 265148
|
| |
|
|
|
|
|
|
| |
This avoids undefined behavior when casting pointers to it. Also make
sure that we don't cast to a derived StringMapEntry before checking for
tombstone, as that may have different alignment requirements.
llvm-svn: 265145
|
| |
|
|
| |
llvm-svn: 265144
|
| |
|
|
|
|
|
|
| |
$vsrc1 -> $src1, $k -> $imm
Differential Revision: http://reviews.llvm.org/D18659
llvm-svn: 265141
|
| |
|
|
|
|
|
| |
Since revision 235394, we no longer perform target specific combines on
build_vector nodes. No functional change intended.
llvm-svn: 265138
|
| |
|
|
| |
llvm-svn: 265135
|
| |
|
|
|
|
|
|
|
|
| |
Summary: The assembler was picking the wrong JR variant because the pre-R6 one was still enabled at R6.
Author: nitesh.jain
Reviewers: vkalintiris, dsanders
Subscribers: dsanders, llvm-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: D18387
llvm-svn: 265134
|
| |
|
|
|
|
| |
Found by msan. Patch by Adrian Kuegel!
llvm-svn: 265133
|
| |
|
|
|
|
|
|
| |
Add a new Intel MCU CPU Lakemont, which doesn't support X87.
Differential Revision: http://reviews.llvm.org/D18650
llvm-svn: 265128
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some ARM instructions encode 32-bit immediates as a 8-bit integer (0-255)
and a 4-bit rotation (0-30, even) in its least significant 12 bits. The
original fixup, FK_Data_4, patches the instruction by the value bit-to-bit,
regardless of the encoding. For example, assuming the label L1 and L2 are
0x0 and 0x104 respectively, the following instruction:
add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260
would be assembled to the following, which adds 1 to r0, instead of 260:
e2800104 add r0, r0, #4, 2 ; equivalently 1
The new fixup kind fixup_arm_mod_imm takes care of the encoding:
e2800f41 add r0, r0, #260
Patch by Ting-Yuan Huang!
llvm-svn: 265122
|
| |
|
|
|
|
|
|
|
| |
When a fixup that can be resolved by the assembler is out of range, we should
report an error in the source, rather than crashing.
Differential Revision: http://reviews.llvm.org/D18402
llvm-svn: 265120
|
| |
|
|
|
|
|
| |
This is to be coherent with Full LTO.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265118
|
| |
|
|
|
|
|
|
|
|
|
| |
The llvm_string_of_message function, called by llvm_raise, calls
LLVMDisposeMessage, which expects the message to be dynamically
allocated; it fails freeing the message otherwise. So always
dynamically allocate with LLVMCreateMessage.
Differential Revision: http://reviews.llvm.org/D18675
llvm-svn: 265116
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Expose LLVMCreateTargetMachineData as data_layout.
As r263530 did for go. From that commit: "LLVMGetTargetDataLayout was
removed from the C API, and then TargetMachine.TargetData was removed.
Later, LLVMCreateTargetMachineData was added to the C API"
Differential Revision: http://reviews.llvm.org/D18677
llvm-svn: 265115
|
| |
|
|
|
|
|
|
| |
This allows the linker to instruct ThinLTO to perform only the
optimization part or only the codegen part of the process.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tail call branch instruction might disappear
Bug Pattern:
# BB#0: # %entry
cmpldi 3, 0
beq- 0, .LBB0_2
# BB#1: # %exit
lwz 4, 0(3)
#TC_RETURNd8 LVComputationKind 0
.LBB0_2: # %cond.false
mflr 0
std 0, 16(1)
stdu 1, -96(1)
.Ltmp0:
.cfi_def_cfa_offset 96
.Ltmp1:
.cfi_offset lr, 16
bl __assert_fail
nop
The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.
Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton
http://reviews.llvm.org/D17606
llvm-svn: 265112
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
of "build-id"
This is intended to be used for ThinLTO incremental build.
Differential Revision: http://reviews.llvm.org/D18213
This is a recommit of r265095 after fixing the Windows issues.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265110
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265109
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide a class to generate a SHA1 from a sequence of bytes, and
a convenience raw_ostream adaptor.
This will be used to provide a "build-id" by hashing the Module
block when writing bitcode. ThinLTO will use this information for
incremental build.
Reapply r265094 which was reverted in r265102 because it broke
MSVC bots (constexpr is not supported).
http://reviews.llvm.org/D16325
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265107
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This changes some dllexport tests, to verify that some symbols that
should not be exported are not, in a way that improves the robustness
of CHECK-SAME interaction with CHECK-NOT.
We plan to enable dllimport/dllexport support for the PS4, and these
changes are for points we noticed in our internal testing.
Patch by Warren Ristow!
llvm-svn: 265106
|