Ping. This change only adds links to files that are already uploaded, so I'm not sure what more I need to do.

There isn't any support for ILP32 in the mainline Linux kernel, and there isn't likely to be. However, mainline glibc has had ILP32 support. I don't know the current status.

LGTM. I think someone else has to approve it.

In D16213 I introduced the MCTargetOptions argument to the MCAsmBackend constructor, as well as in constructor wrapper functions. This change touched multiple (every, probably) backend. Given the extension to embed the ABI in the Triple, can the MCTargetOptions argument be removed? That shouldn't be in this commit, I think.

I'm happy to see this change. It has been on my TO DO list for a very long time. I will review it soon.

I don't think it makes sense to combine two unrelated things SVE and PA support into a combined thing. Since we already have UnsupportedFeatures in every sub-target .td file, I think it would be better to instead have:

It is okay'ish to set CompleteModel = 0 if you're not interested in describing all instructions. The other way is of course to add the missing instruction to the model.

In email Wei asked for help about he following error message:

I know this is a little late, but is the second run line of test/CodeGen/AArch64/arm64-popcnt.ll correct? If I build with -DLLVM_TARGETS_TO_BUILD=AArch64;X86 I get an error. As far as I can tell, using grep -l 'RUN.*triple=armv8' -R ../test/ armv8a is dealt with as an ARM target, not an AArch64 one, which is weird in and of itself.

I think this is a coherent set of changes. Given the current top of trunk, this expands support from just assembly/disassembly of machine instructions to include LLVM IR, right? Such being the case, I think this patch should go in. I have some ideas on how to structure passes so SV IR supporting optimizations can be added incrementally. If anyone thinks such a proposal would help, let me know.

I'm not sure what the proposed split would consist of. Would it be

• A patch consisting of only the changes in Intrinsics.td which would be applied first. Wouldn't the changes in SelectionDAG be required as well?
• Everything but the changes in TargetLibraryInfo.cpp etc. for supporting SLEEF and including any related test cases that would be upstreamed 2nd?

Would the second choice be useful by itself? Either in functionality or improved cross-platform testing before the SLEEF support went in?

It looks like the latest changes address the earlier concerns expressed in the review comments:

Okay, I'll be sure to add "[AArch64]" when I do the commit.

Since I don't perceive a requirement that the benchmark source continue to exactly match that of the original, I would prefer just changing the benchmark source to not conflict.

Remove assumption that the build directory is a subdirectory of the source directory.

Describe distinction between sched model and itinerary vis-a-vis schedcover.py.
Give complete command for llvm-tblgen debug output

If you know the command, I agree that digging through the verbose make output is unnecessary. I'll give the entire command and make your suggested change vis-a-vis distinguishing itinerary and machine scheduler model.

Thanks Stefan. LGTM

LGTM

Used complete file diff

Stefan has been doing the back-end as well.

Ping?

I concur with the analysis for ThunderXT99.

Removed matching on "^SUB" which was inadvertently matching "SUBREG_TO_REG", with resulting failure in test/Codegen/AArch64/machine-combine-madd.ll

There is an issue with madd not being generated when this revision is applied to ToT. I have a fix that I will upload. It appears I have to commandeer the revision to do this?

I'm okay with this change

I can probably scare up whether this impacts ThunderX processors. What benchmark should I look at? OpenSSL?

• 0x07b is now named R_AARCH64_P32_TLSDESC_ADR_PREL21
• "#include... Debug " removed
• Tests for R_AARCH64_P32_TLSLE_LD128_TPREL_LO12 and ...ST..._NC added
• For R_AARCH64_TLSDESC_ADR_PREL19, documented in summary as definition added, but not implemented.
• Documented as definitions added, but not implemented: R_AARCH64_P32_TLSGD_ADR_PREL21, R_AARCH64_P32_TLSGD_ADR_PAGE21, R_AARCH64_P32_TLSGD_ADD_LO12_NC
• I've added tests to arm{64,32}-{elf,tls}-relocs.s. I've added an encoding test for LDST128_ABS_LO12_NC to arm{64,32}-elf-relocs.s instead of where the other encoding tests are, arm{64,32}-tls-relocs.s, as this relocation isn't for TLS.

Address comments about missing tests (for those relocations intended to implemented) and about misnamed relocation.

As noted in the inline comments, there are several relocations with no implementations in LP64 or ILP32. My intent with this patch was towards the goal of ILP32 parity with LP64. I still need to file a defect for the missing functionality.

Ping

Ping

This revision is included in an omnibus ILP32 relocation change: https://reviews.llvm.org/D32072

This revision is included in an omnibus ILP32 relocation change: https://reviews.llvm.org/D32072

This revision is included in an omnibus ILP32 relocation change: https://reviews.llvm.org/D32072

Improve consistency of capitalization of MIPS, types vs. register classes, etc.

Updated per comments.

Thanks for all your comments. I'm about to post a new revision modified per your comments.

I haven't abandoned this patch. In working on this one, I've found several issues that I am going to deal with first.

Added requested explanation of what LSE is.

Ping?

I'm splitting this revision into two parts, One will be to have the target names match those in the GCC proposal (see the gcc-patches mailing list, 1 November 2016, https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00155.html). The other will be a fix to the instruction mapping to scheduling information.

I'm in charge of this revision now.

AArch64 ILP32 relocations for assembly and ELF

Ping?

We also have some parsing tests to make sure we're not loosing anything, but I agree, the number of relevant tests there is not great.

I think this can be a task for a separate patch.

cheers,
--renato

I'm going to be working on this patch from Ananth. For the AsmParser test, I'm assuming that the file being referred to is: unittests/Support/TargetParserTest.cpp? If so, I have several questions:

1. What is this testing exactly? It just seems to be repeating the information in include/llvm/Support/AArch64TargetParser.def
2. Is simply adding "thunderx" to the "CPU" array initialization sufficient?

Add relocations for AArch64 ILP32. Includes:

Does anyone have any comments on the code as it is now, i. e.:

• Relocation names matching standard
• Correct comment about specification version
• Use of macros to reduce duplicate code (both "?:" and error strings)

AArch64 ILP32 relocations for assembly and ELF
Add relocations for AArch64 ILP32. Includes:

Thanks for your detailed comments. I have made the changes suggested earlier with regard to the proper names (R_AARCH32* -> R_AARCH64_P32). I agree with your comment about the repeated code. A macro that mimics the tables in the specification is probably clearer. I'll try that and see how it goes. I also concur with your comment about the text of the error messages.

Thanks for your comments. I'll change the relocation names and change the citation to use the internal revision history name and make a comment about the discrepancy with the cover page.

Trying to get "arc commit" to not complain about "generated from '', but current working copy root is '/llvm/trunk'"

Ping. This change needs to be made once D16213 goes in.

Thanks for your comments. I'll take your advice and push forward.

I'm trying to reconcile how this patch should interact with the set of proposed patches rooted at: https://reviews.llvm.org/D21465
The have similar goals, that is to support ABIs in a uniform fashion.

I've tried doing a commit using "arc commit --revision D16213", but I seem to have forgotten my password. Further, I'm 100% certain my email was set to the one at Apple. Could someone do the commit and the associated clang change for me?

Updated to ToT. Passes "make check-clang"

Rebased against ToT. Passes "make check".

Thanks for the follow up. I haven't gotten back to the work that motivated
the change. Would it be better to somehow retract the change and start
fresh when I pick up the work again? I don't follow LLVM development
closely enough to know the proper procedure.

The FIXME comment doesn't make sense to me. I'm not sure what sanitizer arguments would be passed to the assembler.

Ping.

Did you mean remove the duplication from addPassesToEmitFile mentioned in the FIXME or something else?

I've made the necessary change to clang and put it in: