Undo formatting changes and fix typo in test comment.

Merge fixup_sparc_br16_2/fixup_sparc_br16_14 into a single fixup.

In D142461#4187043, @brad wrote:

Just D142461?

Yes, just this one (D142461). Thanks a lot!

Sorry, just noticed that this was being merged, but can we postpone/revert it at least until D144012 is also merged, @brad?
Without it, backwards branches might be miscompiled when using IAS...

Ping?

Remove stray include statement.

• Fix calculation for fixup_sparc_br16_2.
• Make sure to properly shift fixup values as described in the fixup tables.
• Only emit one R_SPARC_WDISP16 relocation per one fixup_sparc_br16_14/2 pair.

Ping?

Ping?

Split the encoding fix into D144012.

Update update_llc_test_checks testcases.

Update as suggested, remove the conditional on target.

Ping again?

Ping?

• Use MI.isInlineAsm() as suggested
• Clean up unnecessary changes

Ping?

Ping?

Address review comment: list all the types that is supported by SELECT_REG.

Update conditionals, separate the f128 part for easier reading.

Address review comments, and add a hardquad variant of the test case.

In D138922#4011537, @ro wrote:

This patch broke Solaris/sparcv9 bootstrap. Details in Issue #59646.

I noticed that in the "Zero register pair" pattern, LLVM really does not like using an explicit copying from %g0 to set the lower half, even when bitcasted into i32 as in the previous version of the patch, so I generalized the pattern to match the materialization of any (0, X) register pair. This works since we really only care about preventing LLVM from selecting a register pair copy (i.e. COPY G0_G1) during the filling of the upper part.

In D138887#3980307, @jrtc27 wrote:

Are you trying with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON?

Anything else that I need to do here? I can't seem to reproduce the errors locally.

• Address review comments
• Add assembly tests for MOVRri, FMOVRD, and FMOVRQ instruction templates

Address review comments and remove redundant includes.

• Mark i64 zero materialization as for 64-bit target only.
• Use ORrr instead of the default COPY to zero the upper half of a register pair. Using COPY there will result in LLVM changing the COPY G0 operation to a COPY G0_G1 operation, which is not what we want in this case. Note that in all other cases turning COPY G0 to COPY G0_G1 is the right thing to do; zeroing is simply an exception to that rule.

In D138532#3945422, @MaskRay wrote:

I think we usually follow GCC instead of other targets.

Looks okay here too, thanks.

The patch doesn't apply cleanly as-is on my test system (seems like there are some of the proposed changes that's already in main?).
Once I got the patch to apply, though, it seems to be hitting some assertion failures:

Simplify the implementation; in particular, do not trip into the allocator and force instructions to always use %fcc0.
This is to get around the limitation of needing allocatable registers to also be spillable, since, unfortunately, SPARC FCCs only support a very limited set of operations.

Set cc = 0b00 in BPA instruction definition.

Looks okay to me, at least on the SPARC side.
For the CodeGen changes I'm not seeing anything obviously wrong, but it'd be better if someone else also review that part since I'm not very familiar with its workings.

Don't do setHasMultipleConditionRegister.
For now, just disallow deprecated branch forms, the work of enabling whole-FP CCR allocation will be done in a separate patch.

Update the new tests to use update_llc_test_checks.py results.

Thanks, can you please commit it to me, @MaskRay?
My email address is koachan@protonmail.com.

Move all sret-related tests into one file and autogenerate the test cases.

A question about the CI: It says that the build fails because of clang-format errors, yet when I run it locally it says "clang-format did not modify any files". What do I need to do?

Don't include unused headers.

Codestyle changes + check branch opcode instead of subtarget when loading parameters.

• Change codestyle as suggested
• Change parseCondBranch/insertBranch to pass the branch opcode instead of relying on subtarget checking

I have a little bit of question regarding aesthetics: In the text assembly language, if the destination of FP compare is not specified, then it is taken as %fcc0.
(that is, fcmp<s|d|q> rs1, rs2 is encoded in the same way as fcmp<s|d|q> %fcc0, rs1, rs2 in the binary machine language)
Currently LLVM prefers to emit the former form. Is it okay to leave it as-is, or should it be changed so it explicitly spells out the %fcc0 destination?

Change LowerBR_CC to use already-created isV9 rather than passing Subtarget again.

Ping. Is there anything else I should do for this?

Ping. Is there anything else I should do for this?

Ping?

Ping?

Change formatting as suggested by clang-format.

Ping?

Add some comment wrt BPA emission.

Also update other inline asm-related SPARC tests.

LGTM

Ping?

Ping? Anything else needs to be done for this?

Ping? Anything else needs to be done for this?

Ping?

Looks good to me, also all testcases are passing here:

Looks okay here, in particular it doesn't emit FMOVqcc instructions unless hard-quad-float is specified:

define fp128 @fpselect(i32 signext %0, fp128 %1, fp128 %2) {
  %a = icmp eq i32 %0, 0
  %b = select i1 %a, fp128 %2, fp128 %1
  ret fp128 %b
}

Looks okay here too check-unwind tests passes and _Unwind_Backtrace seems to work on Gentoo/sparc64, at least.

In D116857#3294158, @MaskRay wrote:

Co-authored-by: Mark Kettenis

git commit --amend --author='Koakuma <koachan@protonmail.com>'

Will this be fine?

Yeah, that should be okay, I think.

Um... I don't have commit access, so can someone please help committing it for me? My email is koachan@protonmail.com.
Thanks a lot for the help.

Follow @Arfrever & clang-format's suggestions.

Use default constructor for Registers_sparc64.

In D116857#3285773, @MaskRay wrote:

Would it be clearer to have _LIBUNWIND_TARGET_SPARC32 and _LIBUNWIND_TARGET_SPARC64 to indicate 32-bit and 64-bit variants?

You can define _LIBUNWIND_TARGET_SPARC to mean either variant.

Some formatting changes as per @MaskRay and clang-format suggestions.

Distinguish REGISTERS_SPARC from REGISTERS_SPARC64 to make building with -DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON possible.

In D102342#3129148, @LemonBoy wrote:

The section H.12 of the SPARC Architecture manual outlines the whole register remapping process that requires the re-allocation of %oN to free %gN registers if needed, I didn't implement the whole thing because of time/interest constraints but as it's written it should be relatively easy to add the missing steps.

I tried to implement this, but as far as I understand it, it's impossible (or at least very hard) to do when it's already this late because even if we manage to put the load result in a %gN register, there's no way to emit an extra mov to get the value into %o5.
Also, as an additional note, functions that does not contain inline assembly generates the correct code on unpatched LLVM, so I believe the existing register remapping is already mostly working as intended.

In D116857#3277968, @thesamesam wrote:

Thanks for doing the work on this and @kettenis for working on it originally too. I'd love to see this landed.

I've tested this on sparc64 on Gentoo and it doesn't seem to build for me right now at commit bddc814b442ae9f30d62e2f881274d6255411225.

Add .register directive for %g2, %g3, %g6, and %g7 as required by the assembly language.

Ping. Is there anything else that needs to be done?

This fixes the wrong #endif placement in DwarfParser.hpp that causes AArch64 build to fail.