Updating method to use MAchineBasickBlock::iterator&.

Fixing use-after-poison issue detected by ASAN buildbot.

@RKSimon I was writting my comment above just before I saw your message, lucky they went in in the correct order :)
I'm tracking down the source of the invalid tMOVr and I'll raise a ticket with the details.

The newly added frame-chain.ll test uncovered an issue with an invalid use of the tMOVr instruction, which is only available from V6 onwards. The failure was captured by a buildbot with expensive checks enabled.
The issue is unrelated to the codegen changes from this patch, and still happens when compiling the same IR code if the changes are reverted.
Given the above, I've updated the test to use thumbv6m while the issue is not resolved: rGcbcce82ef6b5.

Fixing assertion failure caused by incorrect use of tSTRr.

Avoid scavenging extra register when accessing const pool.

Addressing comments.

Avoiding unecessary uses of FP and addressing review comments.

Addressing review comments.

Fix incorrect use of r11 on load/store instructions.

Adding frame access test coverage, adding check for FrameSetup flag and adjusting calculation of FP value.

Addressing linting messages.

Updating comment.

Using APInt on match/apply functions' interfaces and merging mir test into existing one.

LGTM

LGTM.

The limitation with the registerOptimizerLastEPCallback ordering is that, when they come from different plugins - i.e. different shared libraries -, it is currently based solely on the order of command line options and can't be defined in the code.

Adding subtarget feature to control RME availability.

Rebasing.

Adding RME support to release notes.

LGTM.

This solution works well if both passes are always supposed to be run together. If they should also work as standalone passes, it becomes tricky to figure out at what point each of them should be registered.
This could be done using the legacy pass manager on a hacky kind of way by querying for the passes on the PassRegistry, but this is no longer an option in NPM.

I'd still like to understand exactly what you'd be using this for. As in why does some pass need to run before all other instances of some other pass?

Hi @aeubanks,
As I mentioned, this is mostly targeted on plugin passes. At the moment the NPM only offers the PassBuilder's callbacks level of granularity to control when a plugin pass should be run, which might not be sufficient on some cases. The goal was to provide a more fine grained control over this, allowing plugin implementations to run before other native or plugin passes that migth impact their behavior.
Do you have any suggestions on alternative ways to achieve this? I'm not fond of using pass names here myself and would be more than happy to go for a different implementation.

Ping.

Dropping test's IR section.

LGTM.

This change is no longer relevant after D52010.

The changes from D52010 have removed the conflict that made the spilling of high register necessary.
This patch is no longer relevant. D96335 adds a test covering the high register clobbering scenario.

The truncate conditions look a lot better and the test coverage seems reasonable now.
LGTM.

LGTM.

Ping.

No problem! I've pushed the commit on your behalf.

LGMT.

Ping.