actuall addresses in a .o file, so it is better to let the MachO writer compute
it.

This is good for two reasons. First, areas that shouldn't care about
addresses now don't have access to it. Second, the layout of each section
is independent. I should use this in a subsequent commit to speed it up.

Most of the patch is just removing the section address computation. The two
interesting parts are the change on how we handle padding in the end
of sections and how MachO can get the address of a-b when a and b are in
different sections.

Since now the expression evaluation normally doesn't know the section address,
it will think that a-b needs relocation and let the MachO writer know. Once
it has computed the section addresses, it calls back the expression evaluation
with the section addresses to resolve these expressions.

The remaining problem is the handling of padding. Currently it will create
a special alignment fragment at the end. Since that fragment doesn't update
the alignment of the section, it needs the real address to be computed.

Since now the layout will not compute a-b with a and b in different sections,
the only effect that the special alignment fragment has is update the
address size of the section. This can also be done by the MachO writer.

llvm-svn: 121076

llvm-svn: 121072

Implement jump threading of 'indirectbr' by keeping track of whether we're looking for ConstantInt*s or BlockAddress*s.

llvm-svn: 121066

This will be used to truncate live range of DBG_VALUE instruction by register allocator and friends.

llvm-svn: 121061

If dbg_declare() or dbg_value() is not lowered by isel then emit DEBUG message instead of creating DBG_VALUE for undefined value in reg0.

llvm-svn: 121059

llvm-svn: 121050

patch contributed by Jack Whitham!

llvm-svn: 121049

Use BRAD instead of BRD for indirect branches in MBlaze backend.

patch contributed by Jack Whitham!

llvm-svn: 121044

+ ARM/X86/MBlaze now share a common RecordRelocation
+ ARM/X86/MBlaze arch specific routines are limited to GetRelocType()

llvm-svn: 121043

No functionality change.

llvm-svn: 121042

llvm-svn: 121041

llvm-svn: 121040

llvm-svn: 121038

Address more hazards in the MBlaze delay slot filler.

patch contributed by Jack Whitham!

llvm-svn: 121037

llvm-svn: 121034

freed data to be read. I will open a bug to track it being reenabled.

llvm-svn: 121028

llvm-svn: 121026

llvm-svn: 121024

llvm-svn: 121021

the instruction is predicated, reg0 otherwise.

llvm-svn: 121020

not an immediate. It stores either ARM::CPSR or reg0.

llvm-svn: 121018

as llc + llvm-mc. This time ELF is not changed and I tested that llvm-gcc
bootstrap on darwin10 using darwin9's assembler and linker.

llvm-svn: 121006

linux and darwin assemblers happy :-(

llvm-svn: 121004

that no relocations are used (on MochO).
Fixes llc producing different output from llc + llvm-mc.

llvm-svn: 121000

optimization.

Consider:
static void foo() {
  A = alloca
  ...
}

static void bar() {
  B = alloca
  ...
  call foo();
}

void main() {
  bar()
}

The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar.  When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that.  Then it keeps going
and finds that it now contains a call to foo.  It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it".  The problem with this of course, is that 
the lifetime of A and B are nested, not disjoint.

Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early.  We already have tests for the
basic alloca merging optimization and this does not break them.

llvm-svn: 120995

llvm-svn: 120994

llvm-svn: 120993

llvm-svn: 120991

llvm-svn: 120989

llvm-svn: 120988

llvm-svn: 120987

llvm-svn: 120982

that on the ELF writer to detect a section we created.

llvm-svn: 120981

llvm-svn: 120980

llvm-svn: 120979

llvm-svn: 120978

llvm-svn: 120977

memcpy's like:
  memcpy(A, B)
  memcpy(A, C)

we cannot delete the first memcpy as dead if A and C might be aliases.
If so, we actually get:

  memcpy(A, B)
  memcpy(A, A)

which is not correct to transform into:

  memcpy(A, A)

This patch was heavily influenced by Jakub Staszak's patch in PR8728, thanks
Jakub!

llvm-svn: 120974

llvm-svn: 120971

llvm-svn: 120966