- May 03, 2013
-
-
Tom Stellard authored
This can be optimized using the BFI_INT instruction. llvm-svn: 181033
-
Tom Stellard authored
llvm-svn: 181032
-
Tobias Grosser authored
llvm-svn: 181025
-
Richard Sandiford authored
Another step towards reinstating the SystemZ backend. I'll commit the configure changes separately (TARGET_HAS_JIT etc.), then commit a patch to enable the MCJIT tests on SystemZ. llvm-svn: 181015
-
Ulrich Weigand authored
[SystemZ] Support System Z as host architecture The llvm::sys::AddSignalHandler function (as well as related routines) in lib/Support/Unix/Signals.inc currently registers a signal handler routine via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or similar signal, it will show a stack backtrace, deactivate the handler, and then simply return to the operating system. The intent is that the OS will now retry execution at the same location as before, which ought to again trigger the same error condition and cause the same signal to be delivered again. Since the hander is now deactivated, the OS will take its default action (usually, terminate the program and possibly create a core dump). However, this method doesn't work reliably on System Z: With certain signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored by the kernel on the signal stack frame (which is the location where execution will resume) is not the instruction that triggered the fault, but then instruction *after it*. When the LLVM signal handler simply returns to the kernel, execution will then resume at *that* address, which will not trigger the problem again, but simply go on and execute potentially unrelated code leading to random errors afterwards. To fix this, the patch simply goes and re-raises the signal in question directly from the handler instead of returning from it. This is done only on System Z and only for those signals that have this particular problem. llvm-svn: 181010
-
Amara Emerson authored
Build attribute sections can now be read if they exist via ELFObjectFile, and the llvm-readobj tool has been extended with an option to dump this information if requested. Regression tests are also included which exercise these features. Also update the docs with a fixed ARM ABI link and a new link to the Addenda which provides the build attributes specification. llvm-svn: 181009
-
Richard Sandiford authored
First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
-
Benjamin Kramer authored
llvm-svn: 181005
-
Aaron Ballman authored
llvm-svn: 180992
-
Aaron Ballman authored
llvm-svn: 180991
-
Reid Kleckner authored
llvm-svn: 180983
-
John McCall authored
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
-
Akira Hatanaka authored
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
-
Jyotsna Verma authored
llvm-svn: 180964
-
- May 02, 2013
-
-
Vincent Lejeune authored
llvm-svn: 180960
-
Vincent Lejeune authored
llvm-svn: 180959
-
Vincent Lejeune authored
llvm-svn: 180957
-
Vincent Lejeune authored
llvm-svn: 180956
-
Jyotsna Verma authored
llvm-svn: 180953
-
Shuxin Yang authored
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
-
Pranav Bhandarkar authored
* 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
-
Richard Sandiford authored
...aka a test commit. llvm-svn: 180936
-
Jyotsna Verma authored
* 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
-
Tom Stellard authored
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
-
Tom Stellard authored
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
-
Michael Liao authored
llvm-svn: 180915
-
Michael Liao authored
No functionality change llvm-svn: 180914
-
Michael Liao authored
No functionality change llvm-svn: 180912
-
Evan Cheng authored
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
-
Akira Hatanaka authored
No functionality changes. llvm-svn: 180897
-
Filip Pizlo authored
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
-
Bill Wendling authored
llvm-svn: 180889
-
- May 01, 2013
-
-
Jyotsna Verma authored
llvm-svn: 180885
-
Jyotsna Verma authored
PredicateInstruction function. llvm-svn: 180884
-
Filip Pizlo authored
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
-
Nadav Rotem authored
SROA: Generate selects instead of shuffles when blending values because this 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
-
Chad Rosier authored
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
-
Nadav Rotem authored
Optimize CONCAT_VECTOR nodes that merge EXTRACT_SUBVECTOR values that extract from the same vector. rdar://13402653 PR15866 llvm-svn: 180871
-
Rafael Espindola authored
The cause of the windows failures was fixed by r180791. Revert to the state after Sabre's original revert. Original message: revert r179735, it has no testcases, and doesn't really make sense. llvm-svn: 180844
-
Rafael Espindola authored
Patch by Joshua Magee. llvm-svn: 180842
-