| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
EVT.
llvm-svn: 170183
|
|
|
|
| |
llvm-svn: 169854
|
|
|
|
|
|
| |
EVTs.
llvm-svn: 169848
|
|
|
|
|
|
| |
instead of EVTs.
llvm-svn: 169844
|
|
|
|
|
|
| |
EVT.
llvm-svn: 169842
|
|
|
|
| |
llvm-svn: 169841
|
|
|
|
| |
llvm-svn: 169840
|
|
|
|
| |
llvm-svn: 169773
|
|
|
|
| |
llvm-svn: 169772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
command. Bleh, sorry about this!
llvm-svn: 166596
|
|
|
|
| |
llvm-svn: 166591
|
|
|
|
|
|
|
|
| |
(The change at Clang side was committed in r166345)
2. Cosmetic change in order to conform to coding standards.
llvm-svn: 166350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_debugtrap()
which is supposed to consistently raise SIGTRAP across all systems. In contrast,
__builtin_trap() behave differently on different systems. e.g. it raises SIGTRAP on ARM, and
SIGILL on X86. The purpose of __builtin_debugtrap() is to consistently provide "trap"
functionality, in the mean time preserve the compatibility with on gcc on __builtin_trap().
The X86 backend is already able to handle debugtrap(). This patch is to:
1) make front-end recognize "__builtin_debugtrap()" (emboddied in the one-line change to Clang).
2) In DAG legalization phase, by default, "debugtrap" will be replaced with "trap", which
make the __builtin_debugtrap() "available" to all existing ports without the hassle of
changing their code.
3) If trap-function is specified (via -trap-func=xyz to llc), both __builtin_debugtrap() and
__builtin_trap() will be expanded into the function call of the specified trap function.
This behavior may need change in the future.
The provided testing-case is to make sure 2) and 3) are working for ARM port, and we
already have a testing case for x86.
llvm-svn: 166300
|
|
|
|
|
|
|
|
|
|
| |
not legal. However, it should use a div instruction + mul + sub if divide is
legal. The rem legalization code was missing a check and incorrectly uses a
divrem libcall even when div is legal.
rdar://12481395
llvm-svn: 165778
|
|
|
|
|
|
|
|
|
|
| |
absolute minimum required set. This allows a backend to expand any arbitrary set of comparisons as long as a minimum set is supported.
The minimum set of required instructions is ISD::AND, ISD::OR, ISD::SETO(or ISD::SETOEQ) and ISD::SETUO(or ISD::SETUNE). Everything is expanded into one of two patterns:
Pattern 1: (LHS CC1 RHS) Opc (LHS CC2 RHS)
Pattern 2: (LHS CC1 LHS) Opc (RHS CC2 RHS)
llvm-svn: 165655
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
| |
llvm-svn: 164087
|
|
|
|
|
|
|
|
|
| |
In SelectionDAGLegalize::ExpandLegalINT_TO_FP, expand INT_TO_FP nodes without
using any f64 operations if f64 is not a legal type.
Patch by Stefan Kristiansson.
llvm-svn: 162728
|
|
|
|
|
|
|
| |
handle the cases where the memory value type was illegal.
PR 13111.
llvm-svn: 161565
|
|
|
|
|
|
|
|
| |
Ptr, etc.
No functionality change.
llvm-svn: 160042
|
|
|
|
| |
llvm-svn: 160040
|
|
|
|
|
|
|
| |
Load and Store nodes into their own functions.
No functional change.
llvm-svn: 160037
|
|
|
|
|
|
|
|
|
| |
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.
llvm-svn: 159312
|
|
|
|
|
|
|
|
| |
_umodsi3 libcalls if they have the same arguments. This optimization
was apparently broken if one of the node was replaced in place.
rdar://11714607
llvm-svn: 158900
|
|
|
|
|
|
|
| |
Check that the SDValue TargetLowering::LowerOperation returns is not null
before replacing the original node with the returned node.
llvm-svn: 157873
|
|
|
|
|
|
|
|
|
|
| |
to pass around a struct instead of a large set of individual values. This
cleans up the interface and allows more information to be added to the struct
for future targets without requiring changes to each and every target.
NV_CONTRIB
llvm-svn: 157479
|
|
|
|
|
|
|
|
| |
No in-tree targets exercise this path.
Patch by Micah Villmow.
llvm-svn: 157215
|
|
|
|
|
|
|
| |
may be RAUW'd by the recursive call to LegalizeOps; instead, retrieve
the other operands when calling UpdateNodeOperands. Fixes PR12889.
llvm-svn: 157162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of passing listener pointers to RAUW, let SelectionDAG itself
keep a linked list of interested listeners.
This makes it possible to have multiple listeners active at once, like
RAUWUpdateListener was already doing. It also makes it possible to
register listeners up the call stack without controlling all RAUW calls
below.
DAGUpdateListener uses an RAII pattern to add itself to the SelectionDAG
list of active listeners.
llvm-svn: 155248
|
|
|
|
| |
llvm-svn: 154378
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.
PR12419
rdar://9770785
rdar://11195178
llvm-svn: 154370
|
|
|
|
| |
llvm-svn: 154039
|
|
|
|
|
|
| |
PPC64 SVR4 ABI.
llvm-svn: 153372
|
|
|
|
| |
llvm-svn: 153064
|
|
|
|
|
|
| |
providing a default expansion (FADD+FNEG), and teaching DAGCombine not to form FSUBs post-legalize if they are not legal.
llvm-svn: 152079
|
|
|
|
|
|
| |
direct call.
llvm-svn: 151645
|
|
|
|
|
|
| |
prediction. ...", it is breaking the Clang build during the Compiler-RT part.
llvm-svn: 151630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the processor keeps a return addresses stack (RAS) which stores the address
and the instruction execution state of the instruction after a function-call
type branch instruction.
Calling a "noreturn" function with normal call instructions (e.g. bl) can
corrupt RAS and causes 100% return misprediction so LLVM should use a
unconditional branch instead. i.e.
mov lr, pc
b _foo
The "mov lr, pc" is issued in order to get proper backtrace.
rdar://8979299
llvm-svn: 151623
|
|
|
|
|
|
| |
consistency with setExceptionPointerRegister(...).
llvm-svn: 150460
|
|
|
|
| |
llvm-svn: 149816
|
|
|
|
| |
llvm-svn: 148929
|
|
|
|
| |
llvm-svn: 148578
|
|
|
|
|
|
| |
CodeGen.
llvm-svn: 148218
|
|
|
|
|
|
|
|
| |
Promote for those operations.
Sorry, no test case yet
llvm-svn: 148050
|
|
|
|
|
|
| |
using BUILD_VECTORS we may be using a BV of different type. Make sure to cast it back.
llvm-svn: 147851
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147445
|
|
|
|
| |
llvm-svn: 147400
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
llvm-svn: 146466
|