@efriedma the patch is failing to apply - can you please update your baseline, or move this to a GitHub PR?

Fix test failures

Reduced debug info in test file

PR feedback: now looking for lines for both current func and inlinees in getFunctionLineEntries instead of adding to both in addLineEntry. Switched to .s test.

Fix lld test

Update to HEAD to fix build issue

• Merged in test and build fixes.
• Changed assert to validate that all jump tables had an associated info instruction, rather than checking that all indirect branches have an JT info instruction

Another issue: looks like the names in AArch64Subtarget.h need to be fully decorated, including the leading # - so #__chkstk_arm64ec and #__security_check_cookie_arm64ec.

Ping...

Abandoning: I'm unable to reproduce the issue that I thought I was seeing with this. Sorry for the noise.

Sync to HEAD

Change check in TargetLowering::expandIndirectJTBranch to isOSBinFormatCOFF

• Use getCodeViewFlag instead of isOSWindows to gate adding a jump table debug info node.
• Improve tests to workaround llvm-readobj not working for ARM32 correctly.

Fix MIPS tests

Removed JUMP_TABLE_DEBUG_INFO from IsDebugInstr, this was causing the instruction to be moved or dropped incorrectly.

Fix diff

Fix pseudo instruction getting dropped when building with all optimizations enabled

Remove the "scan back" for a jump table operand and replaced it with an explicit pseudo instruction

@omjavaid this change DID NOT CAUSE THE TEST FAILURE, please see the previous comments where we were discussing this:

In D148761#4323950, @bolshakov-a wrote:

I suspect these changes have broken SymbolFile/PDB/function-nested-block.test. The first failure here: https://lab.llvm.org/buildbot/#/builders/219/builds/2520. And it's hardly due to my changes.

Can we please get this merged in?

• Initialize JumpTableSym integer fields.
• Fix ARM32 to use a base address *after* the branch instructions.

Address PR comments:

• Don't assume branch can use the jump table address.
• Implement ARM32 support and add tests.

Can you give an example of an existing tool which parses these for some useful purpose?

Unfortunately, I can't share specifics since the tools that I am focusing on are Microsoft-internal.

Fixed test failures

Veering slightly offtopic here, but - I'm curious - is it possible to link in regular aarch64 object files in an arm64ec executable (for functions where the calling convention doesn't differ from regular aarch64)? Those object files would only ever be called from arm64ec code (not from x86_64), so I wonder if it would work without all the thunks that are present in arm64ec object files. (In particular, the case I have in mind is cases with handwritten aarch64 assembly.) Would it be possible to mark such functions with a calling convention attribute on the C level, to let the compiler generate code for calling regular aarch64 functions?

We could do something like arm64ec-pc-windows-msvc, I guess. That sort of goes against the spirit of target triples: the first part is usually used to describe the instruction set, and the fourth part is usually used to describe alternate ABI/environment/etc. It's not like "arm64ec" makes sense anywhere other than Windows, anyway.

Of course, everything related to triples is a bit fuzzy; if we want to use AArch64SubArch_arm64ec, there isn't really anything stopping us.

What about split args (i.e., i128)? It's my understanding that these need to be passed indirect, but LLVM automatically splits them into two i64 args.

You may also want to use the exiting llvm/test/CodeGen/AArch64/arm64-platform-reg.ll test case.

In D108679#2972326, @kristof.beyls wrote:

In D108679#2965397, @dpaoliello wrote:

In D108679#2964617, @kristof.beyls wrote:

The performance deprecation of certain forms of IT blocks has been reverted.
The performance deprecation notes are being removed from the Arm ARM.
I am expecting that in the near future, code generation for Arm will be adapted to not enable -mrestrict-it by default at all, following what was already done in gcc at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00134.html.

As such, I'm not sure if this patch is a good thing to implement.
Maybe the guidelines in Microsoft's document you point to (https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160#it-instructions) should be adapted to take into account the above described changes to the ArmARM?

@kristof.beyls Can you please point me to any official documentation or announcement from ARM about this (I've tried looking myself but couldn't see anything)?
I'd be happy to abandon this change and get the Microsoft docs updated if these instructions are no longer deprecated.

I have not found a direct public announcement from Arm about this.
The "performance deprecation for certain forms of IT blocks" notes in the Arm Architecture Reference Manual (ArmARM) should have been all removed from the latest version at https://developer.arm.com/documentation/ddi0487/latest
I've found that a few places were missed and raised a defect against the Arm Architecture Reference Manual to get them all removed.
AFAIK, not having these "performance deprecation" notes in the ArmARM may end up being the only documentation about this.

@rnk @aganea Ping... Just wanted to see what was happening with this change, and if there is anything I can do to help get it merged in.

In D108679#2964349, @mstorsjo wrote:

This change seems fine to me, but can we add some sort of testcase for it? Do we have an existing testcase that check for the default behaviour when targeting armv8 somewhere?

Added tests for Restricting IT blocks for v7 vs v8, optimizing for size and Windows.

In D108679#2964617, @kristof.beyls wrote:

The performance deprecation of certain forms of IT blocks has been reverted.
The performance deprecation notes are being removed from the Arm ARM.
I am expecting that in the near future, code generation for Arm will be adapted to not enable -mrestrict-it by default at all, following what was already done in gcc at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00134.html.

As such, I'm not sure if this patch is a good thing to implement.
Maybe the guidelines in Microsoft's document you point to (https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160#it-instructions) should be adapted to take into account the above described changes to the ArmARM?

In D107784#2957846, @mstorsjo wrote:

In D107784#2957747, @dpaoliello wrote:

@rnk Who can help merge this in?

I might have time to apply, run tests and push it - can you provide the git author line, ie “Real Name <email@address>” to use for the commit?

@rnk Who can help merge this in?

@rnk Can you please merge this in?

Fix ARM IP2State

Only avoid +1 for SEH start addresses

Fix typo

@lxfind Can you please merge this in?

In D88059#2295488, @lxfind wrote:

In D88059#2295409, @dpaoliello wrote:

@lxfind Do you have commit permissions? If so, could you please merge this in?

hmm I still cannot patch this from master. Can you double check that you don't have a local commit in the tree?

Regenerate diff

In D88059#2295449, @lxfind wrote:

In D88059#2295409, @dpaoliello wrote:

@lxfind Do you have commit permissions? If so, could you please merge this in?

Sure! Could you please rebase? Somehow I couldn't apply this patch locally.

Rebase to master

@lxfind Do you have commit permissions? If so, could you please merge this in?

I believe that this commit has the required approvals: can someone please merge it?

Add requested assert