[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[iii at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547

--- Comment #5 from Ilya Leoshkevich <iii at linux dot ibm.com> ---
I've further narrowed this down to the difference between the following
snippets: 

// error: impossible asm constraint
struct {} __thread b;
void c() {
  __asm__("la 0,%0\n"
          :
          : "m" (b)
          : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9",
            "r10", "r12");  // free: r11,r13,r14,r15
}

// works
struct {} b;
void c() {
  __asm__("la 0,%0\n"
          "la 1,%1\n"
          :
          : "m" (b), "m" (b)
          : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9",
            "r10", "r12");  // free: r11,r13,r14,r15
}

The problem appears to be that s390 never allows the register allocator
to use r11 and r15, and also r13 when the function uses the constant
pool, which is the case when TLS variables are used. This leaves us only
with 1 free register r14, and we need 2 in order to access TLS variable.

For z10 and later machines it's in theory possible to free up r13, but I
would use this bug to only fix the ICE.

Vladimir, could you please take a look at the attached patch? I
ran regression with and without it on x86_64, and compare_tests did not
show any new failures.