| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
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: 265166
|
| |
|
|
|
|
|
|
| |
breakage
http://llvm.org/bugs/show_bug.cgi?id=27179
llvm-svn: 265165
|
| |
|
|
| |
llvm-svn: 265164
|
| |
|
|
|
|
| |
Replaced lots of dodgy greps with actual codegen
llvm-svn: 265163
|
| |
|
|
|
|
|
|
| |
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.
llvm-svn: 265162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
dummies sections
Extracts code for initializing dummies sections
to avoid possible duplication in following patches.
Differential review: http://reviews.llvm.org/D18691
llvm-svn: 265159
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Some functions in Writer reports error using HasError, and some reports
their return values. This patch makes them to consistently use HasError.
llvm-svn: 265156
|
| |
|
|
|
|
| |
Thanks to George Rimor for pointing it out.
llvm-svn: 265155
|
| |
|
|
|
|
|
|
| |
fixAbsoluteSymbols fixes linker-created symbol addresses. Since we don't
create such symbols for relocatable output, we don't need to call this
function.
llvm-svn: 265154
|
| |
|
|
|
|
|
| |
Move ifdefs to avoid unused static helpers. Move alignment attribute so
that it is respected in GCC and MSVC.
llvm-svn: 265153
|
| |
|
|
| |
llvm-svn: 265152
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
assignAddressesRelocatable function did not set addresses to sections
despite its name. What it actually did is to set file offsets to sections.
assignAddresses function assigned addresses and file offsets to sections.
So there was a confusion what they were doing, and they had duplicate code.
This patch separates file offset assignments from address assignments.
A new function, assignFileOffsets assign file offsets. assignAddresses
do not care about file offsets anymore.
llvm-svn: 265151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extra fix is to note that it still requires copy relocations.
Original message:
Change how we handle R_MIPS_LO16.
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
P.S.: Suggestions for a better name for the predicate are welcome :-)
llvm-svn: 265150
|
| |
|
|
|
|
|
|
|
| |
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 matches the behavior of both bfd and gold. Looks like we just got
here for mips because of a bad ordering of an if else chain.
llvm-svn: 265147
|
| |
|
|
| |
llvm-svn: 265146
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 265143
|
| |
|
|
|
|
|
| |
We had almost identical code to handle creating a plt entry in two
places.
llvm-svn: 265142
|
| |
|
|
|
|
|
|
| |
$vsrc1 -> $src1, $k -> $imm
Differential Revision: http://reviews.llvm.org/D18659
llvm-svn: 265141
|
| |
|
|
|
|
|
| |
The test was failing on windows because the clean rule (which is executed even if the test is
skipped) returned an error there.
llvm-svn: 265140
|
| |
|
|
| |
llvm-svn: 265139
|
| |
|
|
|
|
|
| |
Since revision 235394, we no longer perform target specific combines on
build_vector nodes. No functional change intended.
llvm-svn: 265138
|
| |
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/20138
Fix: Move method above class that uses it.
Works fine with MSVS.
llvm-svn: 265137
|
| |
|
|
| |
llvm-svn: 265136
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
If a non-affine region PHI is generated we should not move the insert
point prior to the synthezised value in the same block as we might
split that block at the insert point later on. Only if the incoming
value should be placed in a different block we should change the
insertion point.
llvm-svn: 265132
|
| |
|
|
| |
llvm-svn: 265131
|
| |
|
|
| |
llvm-svn: 265130
|
| |
|
|
|
|
|
|
|
| |
That is consistent with other symbols: _edata, _etext
and can help to avoid duplicate code.
Differential revision: http://reviews.llvm.org/D18655
llvm-svn: 265129
|
| |
|
|
|
|
|
|
| |
Add a new Intel MCU CPU Lakemont, which doesn't support X87.
Differential Revision: http://reviews.llvm.org/D18650
llvm-svn: 265128
|
| |
|
|
| |
llvm-svn: 265127
|
| |
|
|
| |
llvm-svn: 265126
|
| |
|
|
|
|
|
|
|
|
| |
This can happen as we look for '<<<<' while scanning tokens but then expect
'<<<<\n' to tell apart perforce from diff3 conflict markers. Just harden
the pointer arithmetic.
Found by libfuzzer + asan!
llvm-svn: 265125
|
| |
|
|
| |
llvm-svn: 265124
|
| |
|
|
| |
llvm-svn: 265123
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
directives.
OpenMP 4.5 allows privatization of non-static data members in non-static
member functions. Patch allows to use and implicit privatization of data
members used as counters in loop-based directives.
llvm-svn: 265121
|
| |
|
|
|
|
|
|
|
| |
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 reverts commit http://reviews.llvm.org/rL265003. After some
thoughts decided to emit errors here.
llvm-svn: 265119
|
| |
|
|
|
|
|
| |
This is to be coherent with Full LTO.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265118
|