Many of these could be much better if we just lowered them all as shuffles - especially for the 256-bit vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256708 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, sanjoy, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D15848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256707 91177308-0d34-0410-b5e6-96231b3b80d8
This is mainly test cases for improvements to insertps matching, but pre-SSE41 shuffles could be improved as well
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256705 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a pass to update catchrets when their successors get cloned; the
existing pass doesn't catch these because it walks the funclet whose
blocks are being cloned but the catchret is in a child funclet.
Also update the test for removing incoming PHI values; when the
predecessor is a catchret, the relevant color is the catchret's parentPad,
not its block's color.
Reviewers: andrew.w.kaylor, rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15840
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256689 91177308-0d34-0410-b5e6-96231b3b80d8
While the original code would work with or without braces, it makes sense to
set HaveSemi to true only if (!HaveSemi), otherwise it's already true, so I
put the assignment inside the if block. This addresses PR25998.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256688 91177308-0d34-0410-b5e6-96231b3b80d8
Recolor the IR to make sure our computed colors are not hiding any bugs.
Also, verifyFunction if we are running some post-preparation operations;
some of these operations can hide latent bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256687 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM's targets need to know if stack pointer adjustments occur after the
prologue. This is needed to correctly determine if the red-zone is
appropriate to use or if a frame pointer is required.
Normally, LLVM can figure this out very precisely by reasoning about the
contents of the MachineFunction. There is an interesting corner case:
inline assembly.
The vast majority of inline assembly which will perform a push or pop is
done so to pair up with pushf or popf as appropriate. Unfortunately,
this inline assembly doesn't mark the stack pointer as clobbered
because, well, it isn't. The stack pointer is decremented and then
immediately incremented. Because of this, LLVM was changed in r256456
to conservatively assume that inline assembly contain a sequence of
stack operations. This is unfortunate because the vast majority of
inline assembly will not end up manipulating the stack pointer in any
way at all.
Instead, let's provide a more principled solution: an intrinsic.
FWIW, other compilers (MSVC and GCC among them) also provide this
functionality as an intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256685 91177308-0d34-0410-b5e6-96231b3b80d8
Not folding these cases tends to avoid partial register updates:
sqrtss (%eax), %xmm0
Has a partial update of %xmm0, while
movss (%eax), %xmm0
sqrtss %xmm0, %xmm0
Has a clobber of the high lanes immediately before the partial update,
avoiding a potential stall.
Given this, we only want to fold when optimizing for size.
This is consistent with the patterns we already have for some of
the fp/int converts, and in X86InstrInfo::foldMemoryOperandImpl()
Differential Revision: http://reviews.llvm.org/D15741
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256671 91177308-0d34-0410-b5e6-96231b3b80d8
This restores the previous behavior of not including the mnemonic in the classes table for every target that starts instruction lines with the mnemonic. Not only did the table size increase by 1 entry, but the class enum increased in size which caused every class in the array to increase in size. It also grew the size of the function that parsers tokens into classes by a substantial amount.
This adds a new HasMnemonicFirst flag to all AsmParsers. It's set to 1 by default and Hexagon target overrides it to 0.
For the X86 target alone this recovers 324KB of size on the llvm-mc executable.
I believe the current state is still a bad design choice for the Hexagon target as it causes most of the parsing to do a linear search through the entire match table to comparing operands against every instruction until it finds one that works. At least for the other targets we do a binary search based on mnemonic over which to do the linear scan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256669 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of the effort/prepration to reduce the size
instr-pgo (object, binary, memory footprint, and raw data).
The functionality is currently off by default and not yet
used by any clients.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256667 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r256642 and restores r256620 now that Tobias has
updated Polly.
There are still some potential problems with the code in Polly that I've
sent post-commit review about, but they're unlikely to break anything in
practice, and I'd like to avoid the rest of LLVM and Clang regressing
here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256656 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested in review for r255909, rename MDMaterialized to AllowTemps,
and identify the name of the boolean flag being set in calls to
saveMetadataList.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256653 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested in review for r255909, add a way to ensure that temporary
MD used as keys in the MetadataToID map during ThinLTO importing are not
RAUWed.
Add support for marking an MDNode as not replaceable. Clear the new
CanReplace flag when adding a temporary MD node to the MetadataToID map
and clear it when destroying the map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256648 91177308-0d34-0410-b5e6-96231b3b80d8
Add an assert suggested in review for r255909 to ensure that MDNodes
saved in the map used for metadata linking are either temporary or
resolved.
Also add a comment clarifying why we may need to save off non-MDNode
metadata.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256646 91177308-0d34-0410-b5e6-96231b3b80d8
The commit we revert is rather small, but it enables a larger piece of new
infrastructure that allows to detected misuses of pointer-traits at compile
time. Unfortunately, this change breaks with the use of incomplete types (e.g.
in Polly). As I am not aware of a simple fix on the Polly side, I temporarely
revert this commit to clean the bots and sync-up with Chandler how to best
adapt to these recent changes.
This reverts commit https://llvm.org/svn/llvm-project/llvm/trunk@256620.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256642 91177308-0d34-0410-b5e6-96231b3b80d8
alignment of the pointee type!
This is the culmination of the ptr-traits work. Now the compiler will
catch me if I try to use a pointer to an empty struct as a key in
a dense map or inside a PointerIntPair or PointerUnion! This is much,
much better than sometimes corrupting data (and other times working
fine) due to insufficient alignment.
It also means that we will be much more diligent about rejecting other
uses of these constructs that aren't safe.
It also means that we can now be more aggressive with the constructs
when we actually have guaranteed higher alignment without specializing
stuff. I'll be going through and cleaning up all the current overrides
of these traits which are no longer necessary.
Many thanks to Richard, David, and others who helped me get all of this
together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256620 91177308-0d34-0410-b5e6-96231b3b80d8
