| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 180992
|
|
|
|
| |
llvm-svn: 180991
|
|
|
|
| |
llvm-svn: 180988
|
|
|
|
| |
llvm-svn: 180983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the "identifier" parsed by the frontend callback by skipping forward
until we've consumed a token that ends at the point dictated by the
callback.
In addition, inform the callback when it's parsing an unevaluated
operand (e.g. mov eax, LENGTH A::x) as opposed to an evaluated one
(e.g. mov eax, [A::x]).
This commit depends on a clang commit.
llvm-svn: 180978
|
|
|
|
|
|
|
|
|
|
|
|
| |
register.
- Define pseudo instructions which store or load ccond field of the DSP
control register.
- Emit the pseudos in MipsSEInstrInfo::storeRegToStack and loadRegFromStack.
- Expand the pseudos before callee-scan save.
- Emit instructions RDDSP or WRDSP to copy between ccond field and GPRs.
llvm-svn: 180969
|
|
|
|
| |
llvm-svn: 180967
|
|
|
|
| |
llvm-svn: 180964
|
|
|
|
| |
llvm-svn: 180960
|
|
|
|
| |
llvm-svn: 180959
|
|
|
|
| |
llvm-svn: 180958
|
|
|
|
| |
llvm-svn: 180957
|
|
|
|
| |
llvm-svn: 180956
|
|
|
|
| |
llvm-svn: 180953
|
|
|
|
|
|
|
|
|
|
|
| |
Actually it took me couple of hours trying to make sense of them and
only to find they are dead code. I guess the original author used
"allSingleSucc" to indicate if there are any critial edge emanating
from some blocks, and tried to perform code motion (actually speculation)
in the presence of these critical edges; but later on he/she changed mind
and decided to perform edge-splitting first.
llvm-svn: 180951
|
|
|
|
| |
llvm-svn: 180949
|
|
|
|
| |
llvm-svn: 180947
|
|
|
|
|
|
|
|
|
|
|
|
| |
* lib/Target/Hexagon/HexagonInstrInfo.td: Add patterns to combine a
sequence of a pair of i32->i64 extensions followed by a "bitwise or"
into COMBINE_rr.
* lib/Target/Hexagon/HexagonPeephole.cpp: Copy propagate Rx in the
instruction Rp = COMBINE_Ir_V4(0, Rx) to the uses of Rp:subreg_loreg.
* test/CodeGen/Hexagon/union-1.ll: New test.
* test/CodeGen/Hexagon/combine_ir.ll: Fix test.
llvm-svn: 180946
|
|
|
|
|
|
| |
...aka a test commit.
llvm-svn: 180936
|
|
|
|
|
|
|
| |
This will make it easier to turn on struct-path aware TBAA since the metadata
format will change.
llvm-svn: 180935
|
|
|
|
|
|
|
|
|
| |
to emitted instructions. Use this if you want an instruction to be
counted towards the prologue or if there is no useful source location.
rdar://problem/13442648
llvm-svn: 180929
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* lib/Target/Hexagon/HexagonInstrInfo.cpp (GetDotNewPredOp):
Given a jump opcode return the right pred.new jump opcode with
a taken vs not-taken hint based on branch probabilities provided
by the target independent module.
* lib/Target/Hexagon/HexagonVLIWPacketizer.cpp: Use the above function.
* lib/Target/Hexagon/HexagonNewValueJump.cpp(getNewvalueJumpOpcode):
Enhance existing function use branch probabilities like
HexagonInstrInfo::GetDotNewPredOp but for New Value (GPR) Jumps.
llvm-svn: 180923
|
|
|
|
|
|
|
|
| |
All but two patterns have been converted to the new syntax. The
remaining two patterns will require COPY_TO_REGCLASS instructions, which
the VLIW DAG Scheduler cannot handle.
llvm-svn: 180922
|
|
|
|
|
|
|
|
| |
Fortunately this pattern never matched, otherwise
we would have generated incorrect code.
Signed-off-by: Christian K??nig <christian.koenig@amd.com>
llvm-svn: 180921
|
|
|
|
|
| |
Contributed-by: Dan Liew <daniel.liew@imperial.ac.uk>
llvm-svn: 180919
|
|
|
|
| |
llvm-svn: 180915
|
|
|
|
|
|
| |
No functionality change
llvm-svn: 180914
|
|
|
|
|
|
| |
No functionality change
llvm-svn: 180912
|
|
|
|
| |
llvm-svn: 180910
|
|
|
|
|
|
|
| |
This tests a case where C1 and C2 were the same but X and Y were different
widths.
llvm-svn: 180907
|
|
|
|
|
|
|
|
|
|
|
| |
at all of the operands. Previously it was skipping over implicit operands which
cause infinite looping when the two-address pass try to reschedule a
two-address instruction below the kill of tied operand.
I'm unable to come up with a reasonably sized test case.
rdar://13747577
llvm-svn: 180906
|
|
|
|
|
|
| |
No functionality changes.
llvm-svn: 180897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like. Previously it was only possible to
create an MCJIT that used CodeModel::JITDefault.
EnableFastISel: It's now possible to turn on the fast instruction selector.
The CodeModel option required some trickery. The problem is that previously, we were ensuring future binary compatibility in
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the
bindings then bzero the remaining bits. This works great but assumes that the bitwise zero equivalent of any field is a
sensible default value.
But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model. In both of those, the default
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.
Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.
llvm-svn: 180893
|
|
|
|
|
|
| |
As DejaGNU is deprecated, it seems pipe-jam issue doesn't exist any more.
llvm-svn: 180892
|
|
|
|
|
|
| |
This avoids namespace collisions with llvm::LLVMTargetMachine.
llvm-svn: 180891
|
|
|
|
|
|
| |
right now.
llvm-svn: 180889
|
|
|
|
| |
llvm-svn: 180885
|
|
|
|
|
|
| |
PredicateInstruction function.
llvm-svn: 180884
|
|
|
|
|
|
|
|
| |
The old jit always uses DW_EH_PE_absptr, but MCJIT can use other encodings.
This is in preparation for adding EH support to MCJIT, but not directly
related, so I am committing it first.
llvm-svn: 180883
|
|
|
|
| |
llvm-svn: 180882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
llvm-svn: 180881
|
|
|
|
|
|
|
|
| |
is the cannonical form.
Shuffles are more difficult to lower and we usually don't touch them, while we do optimize selects more often.
llvm-svn: 180875
|
|
|
|
|
|
|
|
|
| |
report a fatal error. This allows us to continue processing the translation
unit. Test case to come on the clang side because we need an inline asm
diagnostics handler in place.
rdar://13446483
llvm-svn: 180873
|
|
|
|
|
|
|
|
|
| |
Optimize CONCAT_VECTOR nodes that merge EXTRACT_SUBVECTOR values that extract from the same vector.
rdar://13402653
PR15866
llvm-svn: 180871
|
|
|
|
|
|
| |
pointing out that you have to pass additional parameters to llvm-lit and explicitly specify python on the command line.
llvm-svn: 180869
|
|
|
|
|
|
| |
warning C4946: reinterpret_cast used between related classes
llvm-svn: 180852
|
|
|
|
|
|
| |
warning C4800: forcing value to bool 'true' or 'false' (performance warning)
llvm-svn: 180851
|
|
|
|
|
|
| |
windows warning: warning C4946: reinterpret_cast used between related classes.
llvm-svn: 180850
|
|
|
|
|
|
| |
warning C4244: 'argument' : conversion from 'uint64_t' to 'const unsigned int', possible loss of data
llvm-svn: 180847
|
|
|
|
|
|
| |
warning C4244: 'argument' : conversion from 'uint64_t' to 'const unsigned int', possible loss of data
llvm-svn: 180846
|