| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Check that the post RA scheduler is being skipped, regardless of
whether it's the top-down list latency scheduler or the post-RA
MI scheduler.
llvm-svn: 217725
|
| |
|
|
| |
llvm-svn: 217715
|
| |
|
|
|
|
|
|
|
|
| |
Similar to my previous -exports-trie option, the -rebase option dumps info from
the LC_DYLD_INFO load command. The rebasing info is a list of the the locations
that dyld needs to adjust if a mach-o image is not loaded at its preferred
address. Since ASLR is now the default, images almost never load at their
preferred address, and thus need to be rebased by dyld.
llvm-svn: 217709
|
| |
|
|
|
|
|
|
|
|
| |
The raw profiles that are generated in compiler-rt always add padding
so that each profile is aligned, so we can simply treat files that
don't have this property as malformed.
Caught by Alexey's new ubsan bot. Thanks!
llvm-svn: 217708
|
| |
|
|
| |
llvm-svn: 217698
|
| |
|
|
|
|
|
| |
Phabricator Revision: http://reviews.llvm.org/D5278
Patch by Sanjin Sijaric!
llvm-svn: 217693
|
| |
|
|
|
|
|
|
|
|
| |
As far as I can tell UTF-8 has been supported since the beginning of Python's
codec support, and it's the de facto standard for text these days, at least
for primarily-English text. This allows us to put Unicode into lit RUN lines.
rdar://problem/18311663
llvm-svn: 217688
|
| |
|
|
|
|
| |
It was incompatible to Win32 x64.
llvm-svn: 217683
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5046
llvm-svn: 217681
|
| |
|
|
| |
llvm-svn: 217680
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5004
llvm-svn: 217678
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5003
llvm-svn: 217676
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5211
llvm-svn: 217675
|
| |
|
|
|
|
| |
Cross-class copies being expensive is actually a trait of the microarchitecture, but as I haven't yet seen an example of a microarchitecture where they're cheap it seems best to just enable this by default, covering the non-mcpu build case.
llvm-svn: 217674
|
| |
|
|
|
|
|
|
|
| |
vectors.
e.g. when promoting ctlz from <2 x i32> to <2 x i64> we have to fixup
the result by 32 bits, not 64. PR20917.
llvm-svn: 217671
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a call to sys::fs::equivalent that should've been to
CodeCoverageTool::equivalentFiles, which lets us restore the test of
r217476 that was removed in r217478.
This reverts r217478, but the test works this time.
llvm-svn: 217646
|
| |
|
|
|
|
|
| |
The register numbers start at 0, so if only 1 register
was used, this was reported as 0.
llvm-svn: 217636
|
| |
|
|
|
|
|
|
|
|
| |
symbols.
Previously we have only been testing these relocations with external symbols.
<rdar://problem/18308413>
llvm-svn: 217635
|
| |
|
|
|
|
| |
I.e., teach it about 'sext (zext a to ty) to ty2' => zext a to ty2.
llvm-svn: 217629
|
| |
|
|
| |
llvm-svn: 217623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inline asm may specify 'U' and 'X' constraints to print a 'u' for an
update-form memory reference, or an 'x' for an indexed-form memory
reference. However, these are really only useful in GCC internal code
generation. In inline asm the operand of the memory constraint is
typically just a register containing the address, so 'U' and 'X' make
no sense.
This patch quietly accepts 'U' and 'X' in inline asm patterns, but
otherwise does nothing. If we ever unexpectedly see a non-register,
we'll assert and sort it out afterwards.
I've added a new test for these constraints; the test case should be
used for other asm-constraints changes down the road.
llvm-svn: 217622
|
| |
|
|
|
|
| |
Fixes <rdar://problem/18297804>.
llvm-svn: 217620
|
| |
|
|
| |
llvm-svn: 217612
|
| |
|
|
| |
llvm-svn: 217611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do
(shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2)
This is already done for multiplies, but since multiplies
by powers of two are turned into shifts, we also need
to handle it here.
This might want checks for isLegalAddImmediate to avoid
transforming an add of a legal immediate with one that isn't.
llvm-svn: 217610
|
| |
|
|
|
|
|
|
| |
and BR24 relocations.
<rdar://problem/18296496>
llvm-svn: 217605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r189189 implemented AVX512 unpack by essentially performing a 256-bit unpack
between the low and the high 256 bits of src1 into the low part of the
destination and another unpack of the low and high 256 bits of src2 into the
high part of the destination.
I don't think that's how unpack works. AVX512 unpack simply has more 128-bit
lanes but other than it works the same way as AVX. So in each 128-bit lane,
we're always interleaving certain parts of both operands rather different
parts of one of the operands.
E.g. for this:
__v16sf a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };
__v16sf b = { 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
__v16sf c = __builtin_shufflevector(a, b, 0, 8, 1, 9, 4, 12, 5, 13, 16,
24, 17, 25, 20, 28, 21, 29);
we generated punpcklps (notice how the elements of a and b are not interleaved
in the shuffle). In turn, c was set to this:
0 16 1 17 4 20 5 21 8 24 9 25 12 28 13 29
Obviously this should have just returned the mask vector of the shuffle
vector.
I mostly reverted this change and made sure the original AVX code worked
for 512-bit vectors as well.
Also updated the tests because they matched the logic from the code.
llvm-svn: 217602
|
| |
|
|
|
|
| |
strings.
llvm-svn: 217601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an extension of the change made with r215820:
http://llvm.org/viewvc/llvm-project?view=revision&revision=215820
That patch allowed combining of splatted vector FP constants that are multiplied.
This patch allows combining non-uniform vector FP constants too by relaxing the
check on the type of vector. Also, canonicalize a vector fmul in the
same way that we already do for scalars - if only one operand of the fmul is a
constant, make it operand 1. Otherwise, we miss potential folds.
This fold is also done by -instcombine, but it's possible that extra
fmuls may have been generated during lowering.
Differential Revision: http://reviews.llvm.org/D5254
llvm-svn: 217599
|
| |
|
|
|
|
|
|
| |
Now that the operations are all implemented, we can test this sub-arch here.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
llvm-svn: 217595
|
| |
|
|
| |
llvm-svn: 217582
|
| |
|
|
| |
llvm-svn: 217581
|
| |
|
|
|
|
|
|
|
|
|
| |
David Blaikie's commits r217563 & r217564, which added shared_ptr to the
CostPool have fixed some memory leak issues exposed by the PBQP with
coalescing constraints.
The sanitizer bot was failing because of those leaks. Now that the leaks
are gone, we can reenable the aarch64/pbqp test.
llvm-svn: 217580
|
| |
|
|
| |
llvm-svn: 217579
|
| |
|
|
| |
llvm-svn: 217576
|
| |
|
|
|
|
|
| |
name that breaks on some platforms. This part of the test just doesn't
matter...
llvm-svn: 217575
|
| |
|
|
|
|
|
|
|
| |
We used to crash processing any relevant @llvm.assume on a 32-bit target
(because we'd ask SE to subtract expressions of differing types). I've copied
our 'simple.ll' test, but with the data layout from arm-linux-gnueabihf to get
some meaningful test coverage here.
llvm-svn: 217574
|
| |
|
|
| |
llvm-svn: 217570
|
| |
|
|
| |
llvm-svn: 217565
|
| |
|
|
|
|
|
| |
The lost chain resulting in earlier side effecting nodes
being deleted.
llvm-svn: 217561
|
| |
|
|
| |
llvm-svn: 217557
|
| |
|
|
| |
llvm-svn: 217553
|
| |
|
|
|
|
|
|
|
|
| |
The routine that determines an alignment given some SCEV returns zero if the
answer is unknown. In a case where we could determine the increment of an
AddRec but not the starting alignment, we would compute the integer modulus by
zero (which is illegal and traps). Prevent this by returning early if either
the start or increment alignment is unknown (zero).
llvm-svn: 217544
|
| |
|
|
| |
llvm-svn: 217536
|
| |
|
|
|
|
| |
leaks in the allocator
llvm-svn: 217531
|
| |
|
|
|
|
|
|
|
|
|
| |
names controlling this variable.
"Unroll" is not the appropriate name for this variable. Clang already uses
the term "interleave" in pragmas and metadata for this.
Differential Revision: http://reviews.llvm.org/D5066
llvm-svn: 217528
|
| |
|
|
|
|
|
|
|
|
| |
This adds target specific support for using the PBQP register allocator on the
AArch64, for the A57 cpu.
By default, the PBQP allocator is not used, unless explicitely required
on the command line with "-aarch64-pbqp".
llvm-svn: 217504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
using static relocation model and small code model.
Summary: currently we generate GOT based relocations for weak symbol
references regardless of the underlying relocation model. This should
be change so that in static relocation model we use a constant pool
load instead.
Patch from: Keith Walker
Reviewers: Renato Golin, Tim Northover
llvm-svn: 217503
|
| |
|
|
|
|
|
|
|
| |
The only Thumb-1 multi-store capable of using LR is the PUSH instruction, which
translates to STMDB, so we shouldn't convert STMIAs.
Patch by Sergey Dmitrouk.
llvm-svn: 217498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for reading the "bigobj" variant of COFF produced by
cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more than 2**16
sections to COFF.
bigobj brings a few interesting differences with it:
- It doesn't have a Characteristics field in the file header.
- It doesn't have a SizeOfOptionalHeader field in the file header (it's
only used in executable files).
- Auxiliary symbol records have the same width as a symbol table entry.
Since symbol table entries are bigger, so are auxiliary symbol
records.
Write support will come soon.
Differential Revision: http://reviews.llvm.org/D5259
llvm-svn: 217496
|