llvm-svn: 148102

of several newly un-defaulted switches. This also helps optimizers
(including LLVM's) recognize that every case is covered, and we should
assume as much.

llvm-svn: 147861

llvm-svn: 147855

llvm-svn: 147820

opportunities that only present themselves after late optimizations
such as tail duplication .e.g.
## BB#1:
        movl    %eax, %ecx
        movl    %ecx, %eax
        ret

The register allocator also leaves some of them around (due to false
dep between copies from phi-elimination, etc.)

This required some changes in codegen passes. Post-ra scheduler and the
pseudo-instruction expansion passes have been moved after branch folding
and tail merging. They were before branch folding before because it did
not always update block livein's. That's fixed now. The pass change makes
independently since we want to properly schedule instructions after
branch folding / tail duplication.

rdar://10428165
rdar://10640363

llvm-svn: 147716

change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.

llvm-svn: 145714

and code model. This eliminates the need to pass OptLevel flag all over the
place and makes it possible for any codegen pass to use this information.

llvm-svn: 144788

the mailing list. Suggestions for other statistics to collect would be
awesome. =]

Currently these are implemented as a separate pass guarded by a separate
flag. I'm not thrilled by that, but I wanted to be able to collect the
statistics for the old code placement as well as the new in order to
have a point of comparison. I'm planning on folding them into the single
pass if / when there is only one pass of interest.

llvm-svn: 143537

PR11217.

llvm-svn: 142956

block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:

1) It operates on the Machine-IR in the CodeGen layer. This exposes much
   more (and more precise) information and opportunities. Also, the
   results are more stable due to fewer transforms ocurring after the
   pass runs.
2) It uses the generalized probability and frequency analyses. These can
   model static heuristics, code annotation derived heuristics as well
   as eventual profile loading. By basing the optimization on the
   analysis interface it can work from any (or a combination) of these
   inputs.
3) It uses a more aggressive algorithm, both building chains from tho
   bottom up to maximize benefit, and using an SCC-based walk to layout
   chains of blocks in a profitable ordering without O(N^2) iterations
   which the old pass involves.

The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.

Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D

llvm-svn: 142641

  .file filenumber "directory" "filename"

This removes one join+split of the directory+filename in MC internals. Because
bitcode files have independent fields for directory and filenames in debug info,
this patch may change the .o files written by existing .bc files.

llvm-svn: 142300

thanks to Duncan.

llvm-svn: 140850

This helps with porting code from 2.9 to 3.0 as TargetSelect.h changed location,
and if you include the old one by accident you will trigger this assert.

llvm-svn: 140848

We may need an SjLj EH preparation pass for some call site information, at least
in the short term.

llvm-svn: 140674

current IR-level pass.

The old SjLj EH pass has some problems, especially with the new EH model. Most
significantly, it violates some of the new restrictions the new model has. For
instance, the 'dispatch' table wants to jump to the landing pad, but we cannot
allow that because only an invoke's unwind edge can jump to a landing pad. This
requires us to mangle the code something awful. In addition, we need to keep the
now dead landingpad instructions around instead of CSE'ing them because the
DWARF emitter uses that information (they are dead because no control flow edge
will execute them - the control flow edge from an invoke's unwind is superceded
by the edge coming from the dispatch).

Basically, this pass belongs not at the IR level where SSA is king, but at the
code-gen level, where we have more flexibility.

llvm-svn: 140646

No functional change intended.

llvm-svn: 140470

Refactor instprinter and mcdisassembler to take a SubtargetInfo. Add -mattr= handling to llvm-mc. Reviewed by Owen Anderson.

llvm-svn: 139237

These are strictly utilities for registering targets and components.

llvm-svn: 138450

This is useful for unit tests.

llvm-svn: 138028

llvm-svn: 136031

llvm-svn: 136010

There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.

llvm-svn: 135611

- Introduce JITDefault code model. This tells targets to set different default
  code model for JIT. This eliminates the ugly hack in TargetMachine where
  code model is changed after construction.

llvm-svn: 135580

TargetLoweringObjectFileImpl down to MCObjectFileInfo.

TargetAsmInfo is done to one last method. It's *almost* gone!

llvm-svn: 135569

(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.

llvm-svn: 135468

to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.

llvm-svn: 135424

Rename createAsmInfo to createMCAsmInfo and move registration code to MCTargetDesc to prepare for next round of changes.

llvm-svn: 135219

  and MCSubtargetInfo.
- Added methods to update subtarget features (used when targets automatically
  detect subtarget features or switch modes).
- Teach X86Subtarget to update MCSubtargetInfo features bits since the
  MCSubtargetInfo layer can be shared with other modules.
- These fixes .code 16 / .code 32 support since mode switch is updated in
  MCSubtargetInfo so MC code emitter can do the right thing.

llvm-svn: 134884

- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
  to generate asm matcher subtarget feature queries. e.g.
  "ModeThumb,FeatureThumb2" is translated to
  "(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".

llvm-svn: 134678

llvm-svn: 134525

extension points to be used by clang.

llvm-svn: 134444

This fixes the issue noted in PR10251 where early tail dup of bbs with
indirectbr would cause a bb to be duplicated into a loop preheader
and then into its predecessors, creating phi nodes with identical
operands just before register allocation.

This helps with jsinterp.o size (__TEXT goes from 163568 to 126656)
and a bit with performance 1.005x faster on sunspider (jits still enabled).

The result on webkit with the jit disabled is more significant: 1.021x faster.

llvm-svn: 134372

llvm-svn: 133292

The LSDA is a bit difficult for the non-initiated to read. Even with comments,
it's not always clear what's going on. This wraps the ASM streamer in a class
that retains the LSDA and then emits a human-readable description of what's
going on in it.

So instead of having to make sense of:

Lexception1:
        .byte   255
        .byte   155
        .byte   168
        .space  1
        .byte   3
        .byte   26
Lset0 = Ltmp7-Leh_func_begin1
      .long     Lset0
Lset1 = Ltmp812-Ltmp7
      .long     Lset1
Lset2 = Ltmp913-Leh_func_begin1
      .long     Lset2
      .byte     3
Lset3 = Ltmp812-Leh_func_begin1
      .long     Lset3
Lset4 = Leh_func_end1-Ltmp812
      .long     Lset4
      .long     0
      .byte     0
      .byte     1
      .byte     0
      .byte     2
      .byte     125
      .long     __ZTIi@GOTPCREL+4
      .long     __ZTIPKc@GOTPCREL+4

you can read this instead:

## Exception Handling Table: Lexception1
##  @LPStart Encoding: omit
##    @TType Encoding: indirect pcrel sdata4
##        @TType Base: 40 bytes
## @CallSite Encoding: udata4
## @Action Table Size: 26 bytes

## Action 1:
##   A throw between Ltmp7 and Ltmp812 jumps to Ltmp913 on an exception.
##     For type(s):  __ZTIi@GOTPCREL+4 __ZTIPKc@GOTPCREL+4
## Action 2:
##   A throw between Ltmp812 and Leh_func_end1 does not have a landing pad.

llvm-svn: 133286

llvm-svn: 133108

the Win64 EH mechanism to implement GCC-style exceptions. LLVM supports
hardly anything else at this point!

llvm-svn: 132234

should eventually convert to PMBuilder, but I don't plan to do this.

llvm-svn: 131819

llvm-svn: 130959

the final assembly. It is the same technique used when targeting
assemblers that don't support .loc.

llvm-svn: 130587

integrated-as.

llvm-svn: 128431