C code to reproduce the issue, built with

'-O2 -mllvm -tail-merge-size=1 -mllvm -verify-cfiinstrs':

void foo1(int v) __attribute__((noreturn)) {
  if (v == 1) {
    __builtin_trap();
  }
  if (foo2(v)) {
    __builtin_trap();
  }
}

Machine IR before branch-folder:

bb.0.entry:
  CMP32ri8 $edi, 1
  JNE_1 %bb.2
  JMP_1 %bb.1

Split the test.

Thanks for the comments, adding $sp as implicit operand is a lot better, no need to modify ShrinkWrapping then.

Adding implicit operand $sp to the instructions instead of FrameSetup flag.

Updated the long branch test with actual shrink-wrapping.

Added long branch test, used update_llc_test_checks.py to create checks.

Addressed inline comments.

Removed the undocumented gingvt instruction.

That's a good question, I only found it in Faraz's binutils patch, and used that as a reference.

Fixed stupid error.

Comments addressed.

Comments addressed.

Addressed nits.

Updated the code to use ASEPRedicate from D44299.

Abandoned in favour of http://reviews.llvm.org/D8895 .

Obsoleted by D9667.

A rebase.

But we are sorting the table exactly as gas only for easier comparison of the generated o files, aren't we?

In D7414#150147, @rafael wrote:

// There may be more ways to sort the table while respecting the ABI rule;
// we always sort the same way gnu as does, for compatibility.

Still not particularly clear. We *have* to sort it in a way that
causes bfd ld to match the same hi and lo relocations as would be
matched had the .s been assembled by gas.

Cheers,
Rafael

In D7414#147888, @rafael wrote:

Still not there. Which relocation gets matched to another is part of

of the semantics of the assembly file. We have to match gas or

document that we are incompatible.

Copied the sentence from the generic sortRelocs().

That is a very different case. That is about ELF, not mips-ELF.

On ELF, the order is not important, and we just need to make sure it
is deterministic. On mips-ELF it is part of the semantics of the .o.

But it cant introduce a wrong result if another relocation is 1 byte
away, no? We just know that that is not possible? If so please add a
comment about that.

Yes, Mips instructions length is fixed and at least 2 bytes (2 for micromips and mips16, 4 for mips32 and mips64), so there will always be 2 or 4 bytes offset between 2 instructions.

(Some comments disappeared from the previous message.)

A new version of the patch is uploaded.

Hi Rafael, thanks for the link and the review.

Minimal c code to reproduce the error, used to generate vector-multiply.ll
from the patch:

When RegScavenger runs out of registers, it tries to spill one. So it generates
e.g.

Hi Lang, thanks for the review.

ping

This is the list of passing tests now:

LLVM :: ExecutionEngine/MCJIT/cross-module-sm-pic-a.ll
LLVM :: ExecutionEngine/MCJIT/eh-lg-pic.ll
LLVM :: ExecutionEngine/MCJIT/eh-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/hello-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll
LLVM :: ExecutionEngine/MCJIT/non-extern-addend-smallcodemodel.ll
LLVM :: ExecutionEngine/MCJIT/remote/cross-module-sm-pic-a.ll
LLVM :: ExecutionEngine/MCJIT/remote/multi-module-sm-pic-a.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-global-init-nonzero-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-ptr-reloc-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/test-ptr-reloc-sm-pic.ll