| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
instructions when it finds an appropriate pattern.
These are lovely instructions, and its a shame to not use them. =] They
are fast, and can hand loads folded into their operands, etc.
I've also plumbed the comment shuffle decoding through the various
layers so that the test cases are printed nicely.
llvm-svn: 217758
|
| |
|
|
| |
llvm-svn: 217756
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AVX is available, and generally tidy up things surrounding UNPCK
formation.
Originally, I was thinking that the only advantage of PSHUFD over UNPCK
instruction variants was its free copy, and otherwise we should use the
shorter encoding UNPCK instructions. This isn't right though, there is
a larger advantage of being able to fold a load into the operand of
a PSHUFD. For UNPCK, the operand *must* be in a register so it can be
the second input.
This removes the UNPCK formation in the target-specific DAG combine for
v4i32 shuffles. It also lifts the v8 and v16 cases out of the
AVX-specific check as they are potentially replacing multiple
instructions with a single instruction and so should always be valuable.
The floating point checks are simplified accordingly.
This also adjusts the formation of PSHUFD instructions to attempt to
match the shuffle mask to one which would fit an UNPCK instruction
variant. This was originally motivated to allow it to match the UNPCK
instructions in the combiner, but clearly won't now.
Eventually, we should add a MachineCombiner pass that can form UNPCK
instructions post-RA when the operand is known to be in a register and
thus there is no loss.
llvm-svn: 217755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'punpckhwd' instructions when suitable rather than falling back to the
generic algorithm.
While we could canonicalize to these patterns late in the process, that
wouldn't help when the freedom to use them is only visible during
initial lowering when undef lanes are well understood. This, it turns
out, is very important for matching the shuffle patterns that are used
to lower sign extension. Fixes a small but relevant regression in
gcc-loops with the new lowering.
When I changed this I noticed that several 'pshufd' lowerings became
unpck variants. This is bad because it removes the ability to freely
copy in the same instruction. I've adjusted the widening test to handle
undef lanes correctly and now those will correctly continue to use
'pshufd' to lower. However, this caused a bunch of churn in the test
cases. No functional change, just churn.
Both of these changes are part of addressing a general weakness in the
new lowering -- it doesn't sufficiently leverage undef lanes. I've at
least a couple of patches that will help there at least in an academic
sense.
llvm-svn: 217752
|
| |
|
|
|
|
|
|
| |
Use fully qualified name inside a typedef from llvm::iterator_range<...> to
iterator_range. This is reported (rightly I think) by GCC as an
ambiguous name redefinition. Hope this fixes the buildbots.
llvm-svn: 217751
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some ICmpInsts when anded/ored with another ICmpInst trivially reduces
to true or false depending on whether or not all integers or no integers
satisfy the intersected/unioned range.
This sort of trivial looking code can come about when InstCombine
performs a range reduction-type operation on sdiv and the like.
This fixes PR20916.
llvm-svn: 217750
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
replaceAllUsesWith had been modified to allow a DbgNode value to be
replaced by itself. In that case a new node is created by copying the
current DbgNode and the copy is used as replacement value.
When that copying happens, the value stored in this->DbgNode at the end
of RAUW would be a reference to the Node that has just been deleted.
This doesn't produce any bug right now, because the DI node on which we
call RAUW won't be used again.
Reviewers: dblaikie, echristo, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5326
llvm-svn: 217749
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RAUW was only used on DIType to merge declarations and full definitions
of types. In order to support the same functionality for functions and
global variables, move the function up type DI type hierarchy to the
common parent of DIType, DISubprogram and DIVariable which is
DIDescriptor.
This functionality will be exercized when we add the code to emit
imported declarations for forward declared function/variables.
Reviewers: echristo, dblaikie, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5325
llvm-svn: 217748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A DWARFUnitSection is the collection of Units that have been extracted from
the same debug section.
By embeding a reference to their DWARFUnitSection in each unit, the DIEs
will be able to resolve inter-unit references by interrogating their Unit's
DWARFUnitSection.
This is a minimal patch where the DWARFUnitSection is-a SmallVector of Units,
thus exposing exactly the same interface as before. Followup-up patches might
change from inheritance to composition in order to expose only the wanted
DWARFUnitSection abstraction.
Differential Revision: http://reviews.llvm.org/D5310
llvm-svn: 217747
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are super simple. They even take precedence over crazy
instructions like INSERTPS because they have very high throughput on
modern x86 chips.
I still have to teach the integer shuffle variants about this to avoid
so many domain crossings. However, due to the particular instructions
available, that's a touch more complex and so a separate patch.
Also, the backend doesn't seem to realize it can commute blend
instructions by negating the mask. That would help remove a number of
copies here. Suggestions on how to do this welcome, it's an area I'm
less familiar with.
llvm-svn: 217744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support transforming the forms from the new vector shuffle lowering to
use 'movddup' when appropriate.
A bunch of the cases where we actually form 'movddup' don't actually
show up in the test results because something even later than DAG
legalization maps them back to 'unpcklpd'. If this shows back up as
a performance problem, I'll probably chase it down, but it is at least
an encoded size loss. =/
To make this work, also always do this canonicalizing step for floating
point vectors where the baseline shuffle instructions don't provide any
free copies of their inputs. This also causes us to canonicalize
unpck[hl]pd into mov{hl,lh}ps (resp.) which is a nice encoding space
win.
There is one test which is "regressed" by this: extractelement-load.
There, the test case where the optimization it is testing *fails*, the
exact instruction pattern which results is slightly different. This
should probably be fixed by having the appropriate extract formed
earlier in the DAG, but that would defeat the purpose of the test.... If
this test case is critically important for anyone, please let me know
and I'll try to work on it. The prior behavior was actually contrary to
the comment in the test case and seems likely to have been an accident.
llvm-svn: 217738
|
| |
|
|
|
|
|
| |
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
|