| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
|  | 
pointer to a dead function. To make sure it's valid, doFinalization nullptrs
RewindFunction just like the constructor and so it will be found on next run.
llvm-svn: 217737
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
... Just make sure we check uses first so we see the kill first. It
turns out ignoring defs gives some pretty nasty runtime failures.
I'm certain this is the fix but I'm still reducing a testcase.
llvm-svn: 217735
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Extend the logical ops selection to also support non-native types such as i1,
i8, and i16.
Fixes rdar://problem/18330589.
llvm-svn: 217732
 | 
| | 
| 
| 
|  | 
llvm-svn: 217731
 | 
| | 
| 
| 
|  | 
llvm-svn: 217730
 | 
| | 
| 
| 
|  | 
llvm-svn: 217726
 | 
| | 
| 
| 
| 
| 
|  | 
Hopefully, this will appease the bots.
llvm-svn: 217712
 | 
| | 
| 
| 
|  | 
llvm-svn: 217711
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
even when scheduler AliasAnalysis is not
enabled.  A good chunk of the MIsNeedChainEdge() is logic that is valid and should be applied even for targets
that are not using for alias analysis.
llvm-svn: 217706
 | 
| | 
| 
| 
|  | 
llvm-svn: 217705
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary: This will be used in clang.
Test Plan: Will be tested on the clang side.
Reviewers: hansw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5337
llvm-svn: 217702
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
le64 is a generic little-endian 64-bit processor, mimicking le32.
Depends on D5318.
Test Plan: make check-all
Reviewers: dschuff
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5319
llvm-svn: 217697
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Phabricator Revision: http://reviews.llvm.org/D5278
Patch by Sanjin Sijaric!
llvm-svn: 217693
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Vector MUL/MLAs have tied operands, which gives us extra constraints
that we currently can't handle. Instead of silently doing the wrong
thing, remove support to be readded later properly.
llvm-svn: 217690
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Defs are seen before uses, so a def without the kill flag doesn't necessarily
mean that the register is not killed on that instruction. It may be killed
in a later use operand.
llvm-svn: 217689
 | 
| | 
| 
| 
| 
| 
|  | 
Thanks to David Blakie for the in-depth review!
llvm-svn: 217682
 | 
| | 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 217669
 | 
| | 
| 
| 
|  | 
llvm-svn: 217666
 | 
| | 
| 
| 
| 
| 
|  | 
Put them in their own anonymous namespaces. Found by GCC's new -Wodr (PR20915).
llvm-svn: 217662
 | 
| | 
| 
| 
| 
| 
|  | 
make_unique.
llvm-svn: 217655
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
A "stub found found" diagnostic is emitted when RuntimeDyldChecker's stub lookup
logic fails to find the requested stub. The obvious reason for the failure is
that no such stub has been created, but it can also fail for internal symbols if
the symbol offset is not computed correctly (E.g. due to a mangled relocation
addend). This patch adds a comment about the latter case so that it's not
overlooked.
Inspired by confusion experienced during test case construction for r217635.
llvm-svn: 217643
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The register numbers start at 0, so if only 1 register
was used, this was reported as 0.
llvm-svn: 217636
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Use llvm::COFF::BigObjMagic insetad of the string literal.
Also checks the version number.
llvm-svn: 217633
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The byte has no endianness, so these types don't make sense.
uint8_t should be used instead.
llvm-svn: 217631
 | 
| | 
| 
| 
|  | 
llvm-svn: 217630
 | 
| | 
| 
| 
| 
| 
|  | 
I.e., teach it about 'sext (zext a to ty) to ty2' => zext a to ty2.
llvm-svn: 217629
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
And since it /looked/ like the DwarfStrSectionSym was unused, I tried
removing it - but then it turned out that DwarfStringPool was
reconstructing the same label (and expecting it to have already been
emitted) and uses that.
So I kept it around, but wanted to pass it in to users - since it seemed
a bit silly for DwarfStringPool to have it passed in and returned but
itself have no use for it. The only two users don't handle strings in
both .dwo and .o files so they only ever need the one symbol - no need
to keep it (and have an unused symbol) in the DwarfStringPool used for
fission/.dwo.
Refactor a bunch of accelerator table usage to remove duplication so I
didn't have to touch 4-5 callers.
llvm-svn: 217628
 | 
| | 
| 
| 
| 
| 
| 
|  | 
identify_magic recognized a COFF bigobj as an import library file.
This patch fixes that.
llvm-svn: 217627
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The main difference is the removal of
std::error_code exists(const Twine &path, bool &result);
It was an horribly redundant interface since a file not existing is also a valid
error_code. Now we have an access function that returns just an error_code. This
is the only function that has to be implemented for Unix and Windows. The
functions can_write, exists and can_execute an now just wrappers.
One still has to be very careful using these function to avoid introducing
race conditions (Time of check to time of use).
llvm-svn: 217625
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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: 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
 | 
| | 
| 
| 
|  | 
llvm-svn: 217600
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 217597
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Refactored the R600_LDS_1A2D class a bit to get it to actually work.
It seemed to be previously unused and broken.
We also have to disable the conversion to the noret variant for now in
R600ISelLowering because the getLDSNoRetOp method only handles 1A1D LDS ops.
Someone can feel free to modify the AMDGPU::getLDSNoRetOp method to
work for more than 1A1D variants of LDS operations. It's being left as a
future TODO for now.
Signed-off-by: Aaron Watry <awatry at gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
llvm-svn: 217596
 | 
| | 
| 
| 
| 
| 
|  | 
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
llvm-svn: 217594
 | 
| | 
| 
| 
| 
| 
|  | 
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
llvm-svn: 217593
 |