| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
(The Ada bindings probably need it too, but all the
obvious places to change say "do not edit this file".)
llvm-svn: 113618
|
|
|
|
|
|
| |
string.
llvm-svn: 113615
|
|
|
|
| |
llvm-svn: 113614
|
|
|
|
| |
llvm-svn: 113610
|
|
|
|
| |
llvm-svn: 113608
|
|
|
|
|
|
| |
understand (the log file was no help).
llvm-svn: 113605
|
|
|
|
| |
llvm-svn: 113603
|
|
|
|
|
|
| |
"llvm.eh.catch.all.value". Only the name needs to be changed.
llvm-svn: 113600
|
|
|
|
|
|
| |
fixed operands from the total number of operands (including the variadic ones).
llvm-svn: 113597
|
|
|
|
|
|
|
|
| |
a sweet spot in the performance per
code size increase curve.
llvm-svn: 113595
|
|
|
|
|
|
|
| |
that the memoperands are properly set after DAG building and general mucking
about.
llvm-svn: 113585
|
|
|
|
| |
llvm-svn: 113584
|
|
|
|
|
|
|
|
|
|
| |
to use AddrMode4, there was a count of the registers stored in one of the
operands. I changed that to just count the operands but forgot to adjust for
the size of D registers. This was noticed by Evan as a performance problem
but it is a potential correctness bug as well, since it is possible that this
could merge a base update with a non-matching immediate.
llvm-svn: 113576
|
|
|
|
|
|
|
|
|
|
|
| |
take multiple cycles to decode.
For the current if-converter clients (actually only ARM), the instructions that
are predicated on false are not nops. They would still take machine cycles to
decode. Micro-coded instructions such as LDM / STM can potentially take multiple
cycles to decode. If-converter should take treat them as non-micro-coded
simple instructions.
llvm-svn: 113570
|
|
|
|
| |
llvm-svn: 113566
|
|
|
|
|
|
| |
more clear. No functional change.
llvm-svn: 113565
|
|
|
|
|
|
| |
bad as I'd thought.
llvm-svn: 113561
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is different from what the code now uses in a two ways: NamedMDNodes
were considered Values and included in the numbering, and the
function-local metadata counter wasn't reset between functions.
The later problem breaks lazy deserialization, so instead of trying
to emulate the old numbering, just drop the old metadata. The only
in-tree use case is debug info with LTO, where the QOI loss is
considered acceptable.
llvm-svn: 113557
|
|
|
|
|
|
|
|
| |
section.
- This is annoying, because we have to scatter this check everywhere that could emit real data, but I see no better solution.
llvm-svn: 113552
|
|
|
|
| |
llvm-svn: 113551
|
|
|
|
|
|
| |
some data around and implement a couple of move routines to do this.
llvm-svn: 113546
|
|
|
|
| |
llvm-svn: 113539
|
|
|
|
|
|
| |
regular value references.
llvm-svn: 113538
|
|
|
|
| |
llvm-svn: 113537
|
|
|
|
|
|
| |
Truncate when truncating, extend when extending.
llvm-svn: 113536
|
|
|
|
|
|
|
|
|
|
|
| |
with calls, is
not unrolling loops that contain calls that would be better off getting inlined. This mostly
comes up when an interleaved devirtualization pass has devirtualized a call which the inliner
will inline on a future pass. Thus, rather than blocking all loops containing calls, add
a metric for "inline candidate calls" and block loops containing those instead.
llvm-svn: 113535
|
|
|
|
| |
llvm-svn: 113533
|
|
|
|
|
|
|
|
| |
cannot be unrolled. After some discussion,
there seems to be a better way to achieve the same effect.
llvm-svn: 113528
|
|
|
|
|
|
| |
Revert it.
llvm-svn: 113527
|
|
|
|
| |
llvm-svn: 113526
|
|
|
|
|
|
|
|
| |
when we unroll a loop.
Next step is to recalculate the threshold values given this new heuristic.
llvm-svn: 113525
|
|
|
|
| |
llvm-svn: 113523
|
|
|
|
| |
llvm-svn: 113522
|
|
|
|
| |
llvm-svn: 113521
|
|
|
|
|
|
|
|
|
|
| |
instruction in the class would be decoded to. Or zero if the number of
uOPs must be determined dynamically.
This will be used to determine the cost-effectiveness of predicating a
micro-coded instruction.
llvm-svn: 113513
|
|
|
|
|
|
| |
- This code is gross, but does the job for now.
llvm-svn: 113509
|
|
|
|
| |
llvm-svn: 113508
|
|
|
|
| |
llvm-svn: 113501
|
|
|
|
|
|
|
|
|
|
|
| |
and into CodeMetrics. They
don't use any InlineCostAnalyzer state, and are useful for other clients who don't necessarily want to use
all of InlineCostAnalyzer's logic, some of which is fairly inlining-specific.
No intended functionality change.
llvm-svn: 113499
|
|
|
|
|
|
| |
large object file (> 1GB).
llvm-svn: 113494
|
|
|
|
| |
llvm-svn: 113486
|
|
|
|
| |
llvm-svn: 113478
|
|
|
|
|
|
|
| |
the VST pseudos. The VLD/VST scheduling still needs work (see pr6722), but
at least we shouldn't confuse the loads with the stores.
llvm-svn: 113473
|
|
|
|
| |
llvm-svn: 113463
|
|
|
|
|
|
|
| |
uses MMX, even if it also uses other things) from InstrSSE
into InstrMMX. No (intended) functional change.
llvm-svn: 113462
|
|
|
|
| |
llvm-svn: 113461
|
|
|
|
| |
llvm-svn: 113459
|
|
|
|
|
|
|
| |
operand from the pseudo instruction to the new instruction as an implicit use.
This will preserve any other flags (e.g., kill) on the operand.
llvm-svn: 113456
|
|
|
|
| |
llvm-svn: 113455
|
|
|
|
|
|
|
| |
for integer and fp constants. Implement todo to use vfp3 instructions
to materialize easy constants if we can.
llvm-svn: 113453
|