LGTM with a couple of nits.

Thanks again for all of the input on this issue.

Hi @fhahn, this commit seems to break some internal tests of ours. I managed to reduce the assert to the following test:

ah, good ol' refresh delay.

This feature probably should be added as a subtarget of ARMv6m and I guess v8m.baseline too.

We all have some suspicions that it might be awkward to move a DBG_VALUE intrinsic across another one for the *same* *variable*. But we haven't seen that happen in this particular situation when having an end-to-end test with C/C++ input. I'm pretty sure such things can happen in other passes (e.g. CodegenPrepare is moving dbg.value without any checks at all), so it is more like a general concern.

Ah, of course, thanks. And I will add some tests too.

This restriction is in the Armv6M architecture, so I think this should be done in ARMv6m, so it also applies to cortex-m1 and sc000, and I think this also applies to ARMv8mBaseline.

By the way, what is a typical EnvironmentType on BSD systems?

This is now committed as rL335206 and the LTO/Thin LTO bots are happy now. I will follow this up with a change to propagate non-null info.

LGTM Thanks!

Splitted functionality between a few functions with different names. If this patch is good, I'll remove [WIP] status and usage examples (in MICmdCmdExec.cpp file).

Hi Ana, if you're planning on updating it would probably be worth following the work on a replacement for SearchableTable:

Friendly ping.

In D48426#1139318, @thakis wrote:

PCHs aren't compatible with themselves if only the compiler revision changes, so I'm not sure changing that field should be worse than a regular compiler revision update (which happens at every commit). But I don't know what this field is for. I don't remember any trouble from me changing it though, and if it was bad to change it I'd hope there'd be a comment right above the field telling us why. (If I had run into problems, I would've expected me to add a comment like this.)

This problem seems to be aggravated by the new SSAUpdaterBulk() patch pushed on May 12 ( D44282 ) since the PR37745.ll test case does not fail before that date. I don't understand the SSA updater change enough to understand why this problem only happens with the new bulk updates, @mzolotukhin do you happen to know why?

This patch looks fine to me.

Patch updated:
Committed the helper function change with rL335242, so this is only the shuffle fold now.

Rebase