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

Refactor code-size reduction estimation methods out of InlineCostAnalyzer 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