Summary: It turns out that if we don't try to do it at the store location, we can do it before any operation that alias the load, as long as no operation alias the store.
Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15903
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256923 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on D15378, move the mask.empty() tests to after the switch statement and consider any shuffle decode where the extracted target shuffle mask is empty as a failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256921 91177308-0d34-0410-b5e6-96231b3b80d8
...and mark it as merely an input_iterator rather than a forward_iterator,
since it is destructive. And then rewrite == to take advantage of that.
Patch by Alex Denisov!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256913 91177308-0d34-0410-b5e6-96231b3b80d8
If we replace one call-site with another, be sure to move over any
operand bundles that lingered on the old call-site.
This fixes PR26036.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256912 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the properties of memset_pattern16 can be now covered by the generic attributes and inferred by InferFunctionAttrs. The only exceptions are:
- We don't yet have a writeonly attribute for the first argument.
- We don't have an attribute for modeling the access size facts encoded in MemoryLocation.cpp.
Differential Revision: http://reviews.llvm.org/D15879
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256911 91177308-0d34-0410-b5e6-96231b3b80d8
In the discussion on http://reviews.llvm.org/D15730, Andy pointed out we had a utility function for merging MMO lists. Since it turned we actually had two copies and there's another review in progress (http://reviews.llvm.org/D15230) which needs the same, extract it into a utility function and clean up the interfaces to make it easier to use with a MachineInstBuilder.
I introduced a pair here to track size and allocation together. I think we should probably move in the direction of the MachineOperandsRef helper class, but I'm leaving that for further work. I want to get the poison state introduced before I make major changes to the interface.
Differential Revision: http://reviews.llvm.org/D15757
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256909 91177308-0d34-0410-b5e6-96231b3b80d8
confused with what version of mingw is actually installed on the buildbot, and
for now I will just assume this is an unknown version which does not ship with
VersionHelpers.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256902 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is similar to the Python issue#11395. We need to cap the output
size to 32767 on Windows to work around the size limit of WriteConsole().
Reference: https://bugs.python.org/issue11395
Writing a test for this bug turns out to be harder than I thought. I am
still working on it (see phabricator review D15705).
Differential Revision: http://reviews.llvm.org/D15553
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256892 91177308-0d34-0410-b5e6-96231b3b80d8
In an inbounds getelementptr, when an index produces a constant non-negative
offset to add to the base, the add can be assumed to not have unsigned overflow.
This relies on the assumption that addresses can't occupy more than half the
address space, which isn't possible in C because it wouldn't be possible to
represent the difference between the start of the object and one-past-the-end
in a ptrdiff_t.
Setting the NoUnsignedWrap flag is theoretically useful in general, and is
specifically useful to the WebAssembly backend, since it permits stronger
constant offset folding.
Differential Revision: http://reviews.llvm.org/D15544
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256890 91177308-0d34-0410-b5e6-96231b3b80d8
Due to the SGPR init bug, every program claims to use the same number
of SGPRs anyway, so there's no point in trying to shift those registers
down from their initial spot of reservation.
Add a test that uses VGPR spilling and blocks most SGPRs from being used for
the scratch resource register. Previously, this would run into an assertion.
Differential Revision: http://reviews.llvm.org/D15724
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256870 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Most of the tool chain is able to optimize scalar and memcpy like operation effisciently while it isn't that good with aggregates. In order to improve the support of aggregate, we try to change aggregate manipulation into either scalar or memcpy like ones whenever possible without loosing informations.
This is one such opportunity.
Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15894
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256868 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Hi Rafael,
Would you be able to review this patch, please?
(Clang part of the patch is D15832).
When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit.
Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS
limitation. There are two problems in this function that may cause exceeding of the limit:
1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program
path to the command line when it runs the program.
2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails.
Reviewers: rafael, ygao, probinson
Subscribers: asl, llvm-commits
Differential Revision: http://reviews.llvm.org/D15831
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256866 91177308-0d34-0410-b5e6-96231b3b80d8
We queried hasFP before we hit ExpandISelPseudos. ExpandISelPseudos
manipulated state that hasFP relied on, potentially changing the result
after it has been queried elsewhere.
While I am not aware of any particular bug due to this state of affairs,
it seems best to avoid it entirely by changing the state during DAG
construction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256849 91177308-0d34-0410-b5e6-96231b3b80d8
SubtargetFeatures::ApplyFeatureFlag to be static, so that
MCSubtargetInfo doesn't need to instantiate SubtargetFeatures
for nothing. Also change the return type to void, as it
wasn't ever used.
This is a partial commit of http://reviews.llvm.org/D15746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256823 91177308-0d34-0410-b5e6-96231b3b80d8
PBLEND/BLENDPD/BLENDPS are no different to the other target shuffles and this will make future improvements to the target shuffle combines more straightforward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256819 91177308-0d34-0410-b5e6-96231b3b80d8
