| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
| |
class.
llvm-svn: 202953
|
|
|
|
|
|
| |
class.
llvm-svn: 202946
|
|
|
|
|
|
| |
class.
llvm-svn: 202945
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patchpoints already did this. Doing it for stackmaps is a convenience
for the runtime in the event that it needs to scratch register to
patch or perform a runtime call thunk.
Unlike patchpoints, we just assume the AnyRegCC calling
convention. This is the only language and target independent calling
convention specific to stackmaps so makes sense. Although the calling
convention is not currently used to select the scratch registers.
llvm-svn: 202943
|
|
|
|
| |
llvm-svn: 202939
|
|
|
|
|
|
| |
Patch by Manuel Jacob.
llvm-svn: 202936
|
|
|
|
|
|
| |
Found self-hosting clang-cl on windows. :)
llvm-svn: 202935
|
|
|
|
| |
llvm-svn: 202932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selection dag (PR19012)
In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo
to make sure that ESI isn't used as a base pointer register before we choose to
emit rep movs (which clobbers esi).
The problem is that MachineFrameInfo wouldn't know about dynamic allocas or
inline asm that clobbers the stack pointer until SelectionDAGBuilder has
encountered them.
This patch fixes the problem by checking for such things when building the
FunctionLoweringInfo.
Differential Revision: http://llvm-reviews.chandlerc.com/D2954
llvm-svn: 202930
|
|
|
|
|
|
| |
Patch by Manuel Jacob!
llvm-svn: 202928
|
|
|
|
| |
llvm-svn: 202926
|
|
|
|
|
|
|
| |
using a full uint16_t with the flag value... which happens to be
0 or 1. Update the class for bool values and rename functions slightly.
llvm-svn: 202921
|
|
|
|
| |
llvm-svn: 202920
|
|
|
|
| |
llvm-svn: 202919
|
|
|
|
| |
llvm-svn: 202918
|
|
|
|
| |
llvm-svn: 202914
|
|
|
|
| |
llvm-svn: 202913
|
|
|
|
|
|
|
|
|
| |
Currently this code is duplicated across visitSHL, visitSRA and visitSRL. The
plan is to add rotates as clients to this new function.
There is no functional change intended here.
llvm-svn: 202908
|
|
|
|
| |
llvm-svn: 202905
|
|
|
|
| |
llvm-svn: 202902
|
|
|
|
| |
llvm-svn: 202895
|
|
|
|
| |
llvm-svn: 202883
|
|
|
|
|
|
|
|
|
|
| |
This is required to include MSVC's <atomic> header, which we do now in
LLVM.
Tests forthcoming in Clang, since that's where we test semantic inline
asm changes.
llvm-svn: 202865
|
|
|
|
| |
llvm-svn: 202863
|
|
|
|
|
|
|
|
| |
Register the Asm Printer for the ppc64le target.
This fills in a spot that was missed in an earlier change (r187179).
llvm-svn: 202861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously for:
tail call void inttoptr (i64 65536 to void ()*)() nounwind
We would emit:
bl 65536
The immediate operand of the bl instruction is a relative offset so it is
wrong to use the absolute address here.
llvm-svn: 202860
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, attempting to extract lanes 2 and 3 would actually extract lane 1.
The MSA CodeGen tests only covered lanes 0 and 1.
Differential Revision: http://llvm-reviews.chandlerc.com/D2935
llvm-svn: 202848
|
|
|
|
|
|
|
|
|
|
|
| |
source file had already been moved. Also move the unittest into the IR
unittest library.
This may seem an odd thing to put in the IR library but we only really
use this with instructions and it needs the LLVM context to work, so it
is intrinsically tied to the IR library.
llvm-svn: 202842
|
|
|
|
|
|
|
| |
PassInfo structures of the legacy pass manager. Also give it the Legacy
prefix as it is not a particularly widely used header.
llvm-svn: 202839
|
|
|
|
|
|
|
|
|
|
| |
a bit surprising, as the class is almost entirely abstracted away from
any particular IR, however it encodes the comparsion predicates which
mutate ranges as ICmp predicate codes. This is reasonable as they're
used for both instructions and constants. Thus, it belongs in the IR
library with instructions and constants.
llvm-svn: 202838
|
|
|
|
|
|
| |
hardcoded to use IR BasicBlocks.
llvm-svn: 202835
|
|
|
|
|
|
| |
instructions.
llvm-svn: 202834
|
|
|
|
|
|
|
|
|
| |
this would have been required because of the use of DataLayout, but that
has moved into the IR proper. It is still required because this folder
uses the constant folding in the analysis library (which uses the
datalayout) as the more aggressive basis of its folder.
llvm-svn: 202832
|
|
|
|
|
|
| |
IR types.
llvm-svn: 202827
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
llvm-svn: 202824
|
|
|
|
|
|
|
|
|
|
|
| |
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
llvm-svn: 202821
|
|
|
|
|
|
| |
obviously is coupled to the IR.
llvm-svn: 202818
|
|
|
|
|
|
|
| |
abstracting between a CallInst and an InvokeInst, both of which are IR
concepts.
llvm-svn: 202816
|
|
|
|
|
|
|
|
|
| |
name might indicate, it is an iterator over the types in an instruction
in the IR.... You see where this is going.
Another step of modularizing the support library.
llvm-svn: 202815
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
business.
This header includes Function and BasicBlock and directly uses the
interfaces of both classes. It has to do with the IR, it even has that
in the name. =] Put it in the library it belongs to.
This is one step toward making LLVM's Support library survive a C++
modules bootstrap.
llvm-svn: 202814
|
|
|
|
| |
llvm-svn: 202811
|
|
|
|
|
|
| |
bits. It also introduces helper functions that are used to set and clear feature bits as necessary. This directive is a counterpart of -mips32r2 command line options with the exception that it does not influence elf header flags. The usage example is gives in test file.
llvm-svn: 202807
|
|
|
|
| |
llvm-svn: 202806
|
|
|
|
|
|
|
|
|
|
|
| |
out-of-line so that it can refer to the methods on User. As
a consequence, this removes the need to define one template method if
value_use_iterator in the extremely strange User.h header (!!!).
This makse Use.h slightly less peculiar. The only remaining real
peculiarity is the definition of Use::set in Value.h
llvm-svn: 202805
|
|
|
|
|
|
| |
swap implementation.
llvm-svn: 202802
|
|
|
|
|
|
|
|
|
|
| |
inconsistent both with itself and with LLVM at large with formatting.
The *s were on the wrong side, the indent was off, etc etc. This is much
cleaner.
Also, go clang-format laying out the array of tags in nice columns.
llvm-svn: 202799
|
|
|
|
|
|
|
|
| |
the Use class.
More cleanups to come here. This class just needs some TLC.
llvm-svn: 202798
|
|
|
|
| |
llvm-svn: 202791
|
|
|
|
| |
llvm-svn: 202775
|