llvm-svn: 24505

this to be something sane, but in the mean time it is unused, so safe to
make something bogus.

llvm-svn: 24504

llvm-svn: 24503

llvm-svn: 24502

llvm-svn: 24501

llvm-svn: 24500

old ones have been updated to implement the interface.

llvm-svn: 24499

llvm-svn: 24498

llvm-svn: 24497

llvm-svn: 24496

llvm-svn: 24495

llvm-svn: 24494

Random sampling (aka Arnold and Ryder) profiling.  This is still preliminary, but it works on spec on x86 and alpha.  The idea is to allow profiling passes to remember what profiling they inserted, then a random sampling framework is inserted which consists of duplicated basic blocks (without profiling), such that at each backedge in the program and entry into every function, the framework chooses whether to use the instrumented code or the instrumentation free code.  The goal of such a framework is to make it reasonably cheap to do random sampling of very expensive profiling products (such as load-value profiling).

The code is organized into 3 parts (2 passes)
1) a linked set of profiling passes, which implement an analysis group (linked, like alias analysis are).  These insert profiling into the program, and remember what they inserted, so that at a later time they can be queried about any instruction.

2) a pass that handles inserting the random sampling framework.  This also has options to control how random samples are choosen.  Currently implemented are Global counters, register allocated global counters, and read cycle counter (see? there was a reason for it).

The profiling passes are almost identical to the existing ones (block, function, and null profiling is supported right now), and they are valid passes without the sampling framework (hence the existing passes can be unified with the new ones, not done yet).

Some things are a bit ugly still, but that should be fixed up soon enough.

Other todo? making the counter values not "magic 2^16 -1" values, but dynamically choosable.

llvm-svn: 24493

llvm-svn: 24492

llvm-svn: 24491

next up: support argument passing in memory, not just registers

llvm-svn: 24490

Registers.  Apologies to Jim if the scheduling info so far isn't accurate.

There's a few more things like VRsave support that need to be finished up
in my local tree before I can commit code that Does The Right Thing for
turning 4 x float into the various altivec packed float instructions.

llvm-svn: 24489

llvm-svn: 24488

llvm-svn: 24487

llvm-svn: 24486

llvm-svn: 24485

vector operations (load, add, sub, mul).

This allows us to codegen:
void %foo(<4 x float> * %a) {
entry:
  %tmp1 = load <4 x float> * %a;
  %tmp2 = add <4 x float> %tmp1, %tmp1
  store <4 x float> %tmp2, <4 x float> *%a
  ret void
}

on ppc as:
_foo:
        lfs f0, 12(r3)
        lfs f1, 8(r3)
        lfs f2, 4(r3)
        lfs f3, 0(r3)
        fadds f0, f0, f0
        fadds f1, f1, f1
        fadds f2, f2, f2
        fadds f3, f3, f3
        stfs f0, 12(r3)
        stfs f1, 8(r3)
        stfs f2, 4(r3)
        stfs f3, 0(r3)
        blr

llvm-svn: 24484

llvm-svn: 24483

generates it.  Make MVT::Vector expand-only, and remove the code in
Legalize that attempts to legalize it.

The plan for supporting N x Type is to continually epxand it in ExpandOp
until it gets down to 2 x Type, where it will be scalarized into a pair of
scalars.

llvm-svn: 24482

llvm-svn: 24481

llvm-svn: 24480

llvm-svn: 24479

based on TargetType.

llvm-svn: 24478

llvm-svn: 24477

or native Win32

llvm-svn: 24476

conditionals.

llvm-svn: 24475

llvm-svn: 24474

llvm-svn: 24473

llvm-svn: 24472

do it. :)

    <_sabre_> excuses excuses

llvm-svn: 24471

file.

llvm-svn: 24470

llvm-svn: 24469

llvm-svn: 24468

CPI ids

llvm-svn: 24467

CPI names

llvm-svn: 24466