llvm-svn: 77350

llvm-svn: 77340

mode, and "ld64" (the default linker) falls back to it in -static
mode.

llvm-svn: 77334

llvm-svn: 77329

llvm-svn: 77305

llvm-svn: 77301

- This change also makes it possible to switch between ARM / Thumb on a
  per-function basis.
- Fixed thumb2 routine which expand reg + arbitrary immediate. It was using
  using ARM so_imm logic.
- Use movw and movt to do reg + imm when profitable.
- Other code clean ups and minor optimizations.

llvm-svn: 77300

it is highly specific to the object file that will be generated in the end,
this introduces a new TargetLoweringObjectFile interface that is implemented
for each of ELF/MachO/COFF/Alpha/PIC16 and XCore.

Though still is still a brutal and ugly refactoring, this is a major step
towards goodness.

This patch also:
1. fixes a bunch of dangling pointer problems in the PIC16 backend.
2. disables the TargetLowering copy ctor which PIC16 was accidentally using.
3. gets us closer to xcore having its own crazy target section flags and
   pic16 not having to shadow sections with its own objects.
4. fixes wierdness where ELF targets would set CStringSection but not
   CStringSection_.  Factor the code better.
5. fixes some bugs in string lowering on ELF targets.

llvm-svn: 77294

llvm-svn: 77275

Remove TPat. No patterns depend on just isThumb(). Must use either T1Pat (isThumb1Only()) or T2Pat (is Thumb2).

llvm-svn: 77242

llvm-svn: 77233

llvm-svn: 77231

convertToThreeAddress can't handle Thumb2 instructions (which don't have same address mode as ARM instructions).

llvm-svn: 77230

llvm-svn: 77227

llvm-svn: 77222

llvm-svn: 77221

This also fixes potential problems in ARMBaseInstrInfo routines not recognizing thumb1 instructions when 32-bit and 16-bit instructions mix.

llvm-svn: 77218

llvm-svn: 77201

llvm-svn: 77199

instead.

llvm-svn: 77186

instead and drive things based off of that.

llvm-svn: 77184

llvm-svn: 77182

llvm-svn: 77181

Use the right instructions to copy between GPR and the more strictive tGPR classes. t2MOV does not match the RC requirements.

llvm-svn: 77175

llvm-svn: 77174

llvm-svn: 77173

Rename tMOVhi2lor to tMOVgpr2tgpr. It's not moving from a high register to a low register. It's moving from a GPR register class to a more restrictive tGPR class. Also change tMOVlor2hir, and tMOVhir2hir.

llvm-svn: 77172

'unnamed' bss section, but some impls would want a named one.  Since
they don't have consistent behavior, just make each target do their
own thing, instead of doing something "sortof common" then having
targets change immutable objects later.

llvm-svn: 77165

llvm-svn: 77164

llvm-svn: 77145

classes, and migrate existing targets over.

llvm-svn: 77126

 - This was overkill and inconsistently implemented.

llvm-svn: 77114

Patch by Anton Korzh, with some modifications from me.

llvm-svn: 77101

Also, change MDString to use a StringRef.

llvm-svn: 77098

 - Instead of requiring targets to define a JIT quality match function, we just
   have them specify if they support a JIT.

 - Target selection for the JIT just gets the host triple and looks for the best
   target which matches the triple and has a JIT.

llvm-svn: 77060

 - Less boilerplate == good.

llvm-svn: 77052

llvm-svn: 77041

llvm-svn: 77035

llvm-svn: 77026

Before:
      adr r12, #LJTI3_0_0
      ldr pc, [r12, +r0, lsl #2]
LJTI3_0_0:
      .long    LBB3_24
      .long    LBB3_30
      .long    LBB3_31
      .long    LBB3_32

After:
      adr r12, #LJTI3_0_0
      add pc, r12, +r0, lsl #2
LJTI3_0_0:
      b.w    LBB3_24
      b.w    LBB3_30
      b.w    LBB3_31
      b.w    LBB3_32

This has several advantages.
1. This will make it easier to optimize this to a TBB / TBH instruction +
   (smaller) table.
2. This eliminate the need for ugly asm printer hack to force the address
   into thumb addresses (bit 0 is one).
3. Same codegen for pic and non-pic.
4. This eliminate the need to align the table so constantpool island pass
   won't have to over-estimate the size.

Based on my calculation, the later is probably slightly faster as well since
ldr pc with shifter address is very slow. That is, it should be a win as long
as the HW implementation can do a reasonable job of branch predict the second
branch.

llvm-svn: 77024