| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
We only need to describe the writeonly property of one of the arguments. All of the rest of the semantics are nicely described by existing attributes in Intrinsics.td.
Differential Revision: http://reviews.llvm.org/D15880
llvm-svn: 256910
|
| |
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 256909
|
| |
|
|
| |
llvm-svn: 256908
|
| |
|
|
| |
llvm-svn: 256906
|
| |
|
|
|
|
| |
version of shlobj.h includes shobjidl.h and the latter uses the LOGFONTW type.
llvm-svn: 256904
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 256902
|
| |
|
|
| |
llvm-svn: 256901
|
| |
|
|
|
|
| |
the dict entry
llvm-svn: 256900
|
| |
|
|
|
|
| |
the VersionHelpers.h header.
llvm-svn: 256896
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 256892
|
| |
|
|
| |
llvm-svn: 256891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offsets.
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
llvm-svn: 256890
|
| |
|
|
| |
llvm-svn: 256889
|
| |
|
|
| |
llvm-svn: 256884
|
| |
|
|
| |
llvm-svn: 256883
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15901
llvm-svn: 256882
|
| |
|
|
| |
llvm-svn: 256881
|
| |
|
|
| |
llvm-svn: 256876
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: sanjoy, reames
Subscribers: sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D15900
llvm-svn: 256875
|
| |
|
|
|
|
| |
transforms
llvm-svn: 256871
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 256870
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 256868
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
command length limit set by the OS
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
llvm-svn: 256866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although this solves the test case in PR26015:
https://llvm.org/bugs/show_bug.cgi?id=26015
And may solve PR25999:
https://llvm.org/bugs/show_bug.cgi?id=25999
...I suspect this is not the best solution. I think we want to insert the new shuffle
just ahead of the earliest ExtractElementInst that we're replacing, but I don't know
how that should be implemented.
Differential Revision: http://reviews.llvm.org/D15878
llvm-svn: 256857
|
| |
|
|
| |
llvm-svn: 256856
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 256849
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15885
llvm-svn: 256840
|
| |
|
|
|
|
|
|
|
| |
When not all instructions have a scheduling class,
the error message now provides a possible solution.
Differential Revision: http://reviews.llvm.org/D15854
llvm-svn: 256839
|
| |
|
|
|
|
|
|
| |
Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A).
Differential Revision: http://reviews.llvm.org/D15663
llvm-svn: 256828
|
| |
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 256823
|
| |
|
|
| |
llvm-svn: 256820
|
| |
|
|
|
|
| |
PBLEND/BLENDPD/BLENDPS are no different to the other target shuffles and this will make future improvements to the target shuffle combines more straightforward.
llvm-svn: 256819
|
| |
|
|
|
|
| |
It was only needed for rematerialization.
llvm-svn: 256818
|
| |
|
|
|
|
| |
instruction.
llvm-svn: 256817
|
| |
|
|
|
|
| |
pattern in their instructions.
llvm-svn: 256816
|
| |
|
|
|
|
|
|
|
| |
In r256814, we managed to remove catchpads which were trivially redudant
because they were the same SSA value. We can do better using the same
algorithm but with a smarter datastructure by hashing the SSA values
within the catchpad and comparing them structurally.
llvm-svn: 256815
|
| |
|
|
|
|
| |
Remove duplicate catchpad handlers from a catchswitch.
llvm-svn: 256814
|
| |
|
|
|
|
| |
This is already set on the SMRD format class.
llvm-svn: 256813
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously there were three conditionals, checking for global
variables, undef values and everything constant except these two, all three
returning the same value. This commit replaces them by one conditional.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15818
llvm-svn: 256812
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit renames GCRelocateOperands to GCRelocateInst and makes it an
intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of
GCRelocateOperands were changed to use the new intrinsic wrapper instead.
Reviewers: sanjoy, reames
Subscribers: reames, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D15762
llvm-svn: 256811
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for HSA
Summary: This fixes a regression caused by r256282.
Reviewers: arsenm, cfang
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15736
llvm-svn: 256810
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
At least for CoreCLR, a catchpad which immediately executes an
`unreachable` instruction indicates that the exception can never have a
matching type, and so such catchpads can be removed, and so can their
catchswitches if the catchswitch becomes empty.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15846
llvm-svn: 256809
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The red zone consists of 128 bytes beyond the stack pointer so that the
allocation of objects in leaf functions doesn't require decrementing
rsp. In r255656, we introduced an optimization that would cheaply
materialize certain constants via push/pop. Push decrements the stack
pointer and stores it's result at what is now the top of the stack.
However, this means that using push/pop would encroach on the red zone.
PR26023 gives an example where this corrupts an object in the red zone.
llvm-svn: 256808
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We had to sets of identical FLAT patterns one inside the
HasFlatAddressSpace predicate and one inside the useFlatForGloabl
predicate. This patch merges these sets into a single pattern
under the isCIVI predicate.
The reason we can remove the predicates is that when MUBUF instructions
are legal, the instruction selector will prefer selecting those over
FLAT instructions because MUBUF patterns have a higher complexity score.
So, in this case having patterns for FLAT instructions will have no effect.
This change also simplifies the process for forcing global address space
loads to use FLAT instructions, since we no only have to disable the
MUBUF patterns instead of having to disable the MUBUF patterns and
enable the FLAT patterns.
Reviewers: arsenm, cfang
Subscribers: llvm-commits
llvm-svn: 256807
|
| |
|
|
|
|
|
|
|
|
| |
If we encounter a noalias call that alias analysis can't analyse, we can fall down into the generic call handling rather than giving up entirely. I noticed this while reading through the code for another purpose.
I can't seem to write a test case which changes; that sorta makes sense given any test case would have to be an inconsistency in AA. Suggestions welcome.
Differential Revision: http://reviews.llvm.org/D15825
llvm-svn: 256802
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately this fix had the effect of exposing the
-verify-machineinstrs FIXME of X86InstrInfo.cpp in two testcases for
which I disabled it for now.
Two testcases also have additional pushq/popq where the corrected code
cannot prove that %rax is dead any longer. Looking at the examples, this
could potentially be fixed by improving computeRegisterLiveness() to check
the live-in lists of the successors blocks when reaching the end of a
block.
This fixes http://llvm.org/PR25951.
llvm-svn: 256799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enabling this feature will account for the two SGPRs used by the hardware
to store the XNACK_MASK physically.
The hardware only requires this reservation when the XNACK feature is
explicitly enabled. At some point, HSA will probably want to do that, but
it does increase SGPR register pressure, so leave it disabled by default
for now (but do add a small test).
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15869
llvm-svn: 256794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
with instructions of token type
Summary: This patch fixes a bug in prepareICWorklistFromFunction, where the loop becomes infinite with instructions of token type. The patch checks if the instruction is token type, and if so it updates EndInst with the current instruction.
Reviewers: reames, majnemer
Subscribers: llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D15859
llvm-svn: 256792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update some comments to be more explicit.
Change bypassSlowDivision and the functions it calls so that they take
BasicBlock*s and Instruction*s, rather than Function::iterator&s and
BasicBlock::iterator&s.
Change the APIs so that the caller is responsible for updating the
iterator, rather than the callee. This makes control flow much easier
to follow.
Patch by Justin Lebar!
llvm-svn: 256789
|
| |
|
|
|
|
|
|
|
|
|
| |
r256763 had promoteLoopAccessesToScalars check for the existence of a
catchswitch when the exit blocks were populated but
promoteLoopAccessesToScalars may be called with a prepopulated set of
exit blocks which would also need to be checked.
This fixes PR26019.
llvm-svn: 256788
|