| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 78455
|
| |
|
|
| |
llvm-svn: 78454
|
| |
|
|
| |
llvm-svn: 78453
|
| |
|
|
|
|
| |
error condition get trapped with an assert.
llvm-svn: 78449
|
| |
|
|
| |
llvm-svn: 78447
|
| |
|
|
| |
llvm-svn: 78444
|
| |
|
|
| |
llvm-svn: 78443
|
| |
|
|
| |
llvm-svn: 78432
|
| |
|
|
| |
llvm-svn: 78430
|
| |
|
|
| |
llvm-svn: 78428
|
| |
|
|
| |
llvm-svn: 78426
|
| |
|
|
| |
llvm-svn: 78425
|
| |
|
|
|
|
| |
number of ARM tests.
llvm-svn: 78421
|
| |
|
|
| |
llvm-svn: 78420
|
| |
|
|
| |
llvm-svn: 78419
|
| |
|
|
| |
llvm-svn: 78418
|
| |
|
|
| |
llvm-svn: 78416
|
| |
|
|
| |
llvm-svn: 78411
|
| |
|
|
| |
llvm-svn: 78410
|
| |
|
|
| |
llvm-svn: 78405
|
| |
|
|
| |
llvm-svn: 78404
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
llvm-svn: 78400
|
| |
|
|
| |
llvm-svn: 78399
|
| |
|
|
| |
llvm-svn: 78398
|
| |
|
|
| |
llvm-svn: 78397
|
| |
|
|
|
|
|
|
|
|
| |
LoopDependenceAnalysis::getLoops is currently O(N*M) for a loop-nest of
depth N and a compound SCEV of M atomic SCEVs. As both N and M will
typically be very small, this should not be a problem. If it turns out
to be one, rewriting getLoops as SCEVVisitor will reduce complexity to
O(M).
llvm-svn: 78394
|
| |
|
|
|
|
| |
preference; no functional change.
llvm-svn: 78391
|
| |
|
|
|
|
| |
Patch by Jakub Staszak.
llvm-svn: 78388
|
| |
|
|
| |
llvm-svn: 78383
|
| |
|
|
| |
llvm-svn: 78382
|
| |
|
|
| |
llvm-svn: 78381
|
| |
|
|
|
|
|
| |
i386-apple-darwin9. This presumably will get fixed once the generated code
improves.
llvm-svn: 78379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Still not very sane, but a least its not 60k lines on X86. :)
- In terms of correctness, currently some things are hard wired for X86, and we
still don't properly resolve ambiguities (this is ignoring the instructions
we don't even match due to funny .td stuff or other corner cases).
The high level changes:
1. Represent tokens which are significant for matching explicitly as separate
operands. This uniformly handles not only the instruction mnemonic, but
also 'signficiant' syntax like the '*' in "call * ...".
2. Separate the matching of operands to an instruction from the construction of
the MCInst. In theory this can be done during matching, but since the number
of variations is small I think it makes sense to decompose the problems.
3. Improved a few of the mechanisms to at least successfully flatten / tokenize
the assembly strings for PowerPC and ARM.
4. The comment at the top of AsmMatcherEmitter.cpp explains the approach I'm
moving towards for handling ambiguous instructions. The high-bit is to infer
a partial ordering of the operand classes (and force the user to specify one
if we can't) and use that to resolve ambiguities.
llvm-svn: 78378
|
| |
|
|
| |
llvm-svn: 78377
|
| |
|
|
|
|
| |
a def of the exact register rather than a super-register.
llvm-svn: 78376
|
| |
|
|
| |
llvm-svn: 78370
|
| |
|
|
|
|
| |
passes.
llvm-svn: 78369
|
| |
|
|
| |
llvm-svn: 78367
|
| |
|
|
| |
llvm-svn: 78366
|
| |
|
|
| |
llvm-svn: 78365
|
| |
|
|
| |
llvm-svn: 78363
|
| |
|
|
| |
llvm-svn: 78362
|
| |
|
|
|
|
|
|
|
|
| |
The semantics of such instructions are unpredictable. We have just been lucky that tests have been passing.
This patch takes pain to ensure all the PEI lowering code does the right thing when lowering frame indices, insert code to manipulate stack pointers, etc. It's also custom lowering dynamic stack alloc into pseudo instructions so we can insert the right instructions at scheduling time.
This fixes PR4659 and PR4682.
llvm-svn: 78361
|
| |
|
|
| |
llvm-svn: 78360
|
| |
|
|
|
|
| |
stuff as it was only meant for debugging the solver.
llvm-svn: 78359
|
| |
|
|
|
|
| |
based solver, but I'll be working to improve that. The PBQP allocator has been updated to use the new solver.
llvm-svn: 78354
|
| |
|
|
|
|
| |
produced a CFG it wasn't prepared for.
llvm-svn: 78351
|
| |
|
|
| |
llvm-svn: 78350
|
| |
|
|
|
|
| |
module as first argument.
llvm-svn: 78340
|
| |
|
|
|
|
| |
If we need it one day, there is nothing wrong with putting it back in.
llvm-svn: 78337
|