In D63508#1550668, @rsmith wrote:

Perhaps we should rewrite all #if-like directives to #if 0 or #if 1?

-O0 always inline isn't working because the frontend is emitting a store of vector type to memory then a load of x86_mmx to do the type coercion. The caller does the opposite to coerce back from mmx. This -O0 pipeline isn't capable of getting rid of these redundant store/load pairs. We might have a better chance if we just emitted bitcasts.

For this bug, whatever we do with a mir test, it is not going to be reliable in failing if the bug is present. Maybe there is a unit testing framework for LiveRangeCalc tests that I could add a test to.

In D43256#1545519, @samparker wrote:

Do you have any benchmark numbers to show that this is generally profitable? From our downstream testing, it is not clear that this change is beneficial.

Hi JF. Thanks for working on this, nice improvement to error handling!

David Malcon - GCC: “I think we'd want to *not* warn if either of the operands are from a macro expansion.“

I see we don't have any tests for inalloca to model this on, so I think we should skip that for this change. I'll add one later that handles arguments as well, since those are interesting.

In D63488#1548991, @probinson wrote:

I see the point; certainly when someone emails a patch, the first response is almost always "can you put this on Phab."

There was talk at some point about connecting Phab with github authentication, somehow? If people can use an existing account then the you-need-to-register-first objection goes away.

std::next

LGTM with a few nits.

So we would need to mark every instruction that uses any part of DSPControl as having an post-isel hook and there are more than 100 instructions