• Rebase on latest main

This needs to be rebased on latest main.

• Rebase on main since its been a while

• Reduced the number of test lines in target-data.c, since we don't have to check for every combination of arch,cpu for the SystemZ target (for both elf and z/OS)

• Update to the documentation as well in account for the update to the global prefix.

In D109362#3001294, @uweigand wrote:

In D109362#3000284, @anirudhp wrote:

In D109362#2999688, @uweigand wrote:

Looking at the common code parts, it seems the behavior of MM_GOFF is actually identical to MM_ELF. Is this correct? If so, do we really need a different format type here?

At a future point, we will be changing the local and global prefixes. At that point we would still need a separate MM_GOFF field. I feel it would be a bit better to enforce it from now itself.

I see. Is there a reason why we cannot use the "correct" prefixes to begin with?

• Introduce separate label prefix for MM_GOFF

In D109362#2999688, @uweigand wrote:

Looking at the common code parts, it seems the behavior of MM_GOFF is actually identical to MM_ELF. Is this correct? If so, do we really need a different format type here?

Ping :)

• Condensed the lit test a bit.

In D107911#2949414, @anirudhp wrote:

This patch still fails on the PPC64LE-RHEL Bot (https://lab.llvm.org/buildbot/#/builders/57/builds/9429). Could we please revert this patch or add a follow up fix to it? (The fix should be to explicitly initialize all fields in the struct within the initializer list (in lines 128 - 131) of the Thread::Params struct)

Awesome! Thanks!

This patch still fails on the PPC64LE-RHEL Bot (https://lab.llvm.org/buildbot/#/builders/57/builds/9429). Could we please revert this patch or add a follow up fix to it? (The fix should be to explicitly initialize all fields in the struct within the initializer list (in lines 128 - 131) of the Thread::Params struct)

In builds with the -Werror -Wmissing-field-initializers option(s) enabled, the following instantiation will cause an error.

Thread::Params tests[] = {
    {1, 0, 1, true},  {4, 0, 2, true},
    {4, 2, 2, true},  {8, 3, 1, true},
    {2, 1, 1, true},  {1, 1, 1, false},
    {8, 5, 4, false}, {4, static_cast<uptr>(-1l), 4, false},
};

• For the GOFFUniquingMap map, replace the key from a struct to a standard std::string as the Key. This should eliminate the need for the struct and condenses the getGOFFSection function a bit more

• Introduced GOFF support in the TargetLoweringObjectImpl phase, so that we correctly deduce the sections to print out, and not fall back on the default ELF sections.
• This was what was happening previously, with a mix of both GOFF sections and ELF sections.

• Addressing comments

• Rebasing on latest to see if the test failures go away

• Rebase on latest.

• Rebase on latest

In D105142#2862592, @jyknight wrote:

This code doesn't handle multiple alternatives in a constraint.

E.g. "={eax}{ebx}" or "={eax}{ebx},m".

See the GCC docs for the C-level syntax
https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html#Multi-Alternative
and LLVM IR docs for the IR syntax:
https://llvm.org/docs/LangRef.html#constraint-codes

LLVM doesn't handle alternatives very well in the backend, but Clang at least should parse and properly generate LLVM asm strings for these cases I think.

@MaskRay Could you please look at the latest changeset, I have added your example as a separate test case for the x86 target.

• Something went wrong with the previous time updating the diff. I'm not too sure, but I'm just doing it again, and this time the it looks a lot better.

• Disable constraint simplification when you already have a constraint of the form {...}. Constraint simplification is usually done character by character, with different targets having different implementations.
• Furthermore, a constraint of the form {...} already maps to the LLVM inline assembly IR that tells the backend to allocate a suitable physical register.

In D105142#2860885, @MaskRay wrote:

This is great.

unsigned long foo(unsigned long addr, unsigned long a0,
                  unsigned long a1, unsigned long a2,
                  unsigned long a3, unsigned long a4,
                  unsigned long a5) {
  unsigned long result asm("rax");
  unsigned long b2 asm("rdx") = a2;
  unsigned long b3 asm("rcx") = a3;
  unsigned long b4 asm("r8") = a4;
  unsigned long b5 asm("r9") = a5;
  asm("call *%1" : "=r" (result) : "{rax}"(addr), "{rdi}"(a0), "{rsi}"(a1), "r"(b2), "r"(b3), "r"(b4), "r"(b5));
  return result;
}

this compiles to`%0 = tail call i64 asm "call *$1", "=r,{r{ax}x},{r{dx}i},{rsi},r,r,r,r,~{dirflag},~{fpsr},~{flags}"(i64 %addr, i64 %a0, i64 %a1, i64 %a2, i64 %a3, i64 %a4, i64 %a5) #1, !srcloc !3`
(note {r{ax}x},{r{dx}i}) which will cause a backend failure error: couldn't allocate input reg for constraint '{r{dx}'.
Can you investigate it?

In D105142#2849835, @theraven wrote:

The code looks fine but it would be good to see some docs along with it. We're currently missing docs on inline assembly entirely and the GCC ones are somewhat... opaque when it comes to describing how constraints work.

That's true now. The "implicit assumption" is that this will never change in the future.

• More explicit check which eliminates implicit assumptions

In D103343#2789121, @uweigand wrote:

Maybe it would be clearer to be explicit and write:

if (C.getTargetTriple().isSystemZ() && C.getTargetTriple().isOSzOS())

This should have the same effect