llvm-svn: 113637

llvm-svn: 113632

(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

Lower the unrolling theshold to 150.  Empirical tests indicate that this is 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

 - 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

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

Revert r113439, which relaxed the requirement that loops containing calls cannot be unrolled.  After some discussion,
there seems to be a better way to achieve the same effect.

llvm-svn: 113528

llvm-svn: 113527

llvm-svn: 113526

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