Following release cherry-pick workflow.

Fix discrepency with original patch.

cherry-picked to release/16.x

In D143233#4161909, @aaron.ballman wrote:

In D143233#4160206, @efriedma wrote:

Maybe worth cherry-picking to 16 branch? I think someone will need to rebase onto the branch for that, though; there was merge conflict on the microsoft-abi-eh-cleanups.cpp change.

I wouldn't be opposed to picking this onto 16 given that it's fixing an ABI issue, if someone wants to do the work to cherry-pick it.

Jacob Young <jacobly0@users.noreply.github.com>

I was hoping @rnk was available for review, but otherwise this is ready to land and I don't have commit access.

Fix bad diff update.

Address review comments.

Cleanup and minor fixes.

Added regression test specific to the issue.

Could someone commit this for me? Thanks.

I don't have commit access, could someone commit this for me please.

I would have, but it was triggered by an out of tree backend. In order to trigger it, a backend would need to overload TargetLowering::IsDesirableToPromoteOp to return true for a type for which ISD::SIGN_EXTEND_INREG is marked illegal. In tree, only X86 overloads and sometimes returns true for MVT::i16 yet it marks setOperationAction(ISD::SIGN_EXTEND_INREG, MVT::i16 , Legal);.

I don't have commit access so if this is good to go could you commit it for me? Meanwhile, I'll work on actually cleaning up these two transforms.

Rebased and added fixmes.

All that needs to be changed to fix the test91 miscompile is changing ShiftAmt < ASize to ShiftAmt <= SExtSize - ASize. However, making this change actually introduces the test93 miscompile because the original code already assured that ShiftAmt < ASize (which is correct for avoiding a ub shift, but incorrect for avoiding pulling zero bits into the value). Note that by far the most common case of SExtSize >= 2*ASize (which is always true when all types are powers of 2) doesn't actually miscompile (because then ASize <= SExtSize - ASize anyway). I was planning on adding more optimization opportunities in a separate patch, but I'm not sure how to separate this change without introducing a miscompile. I could separate out the naming common subexpressions with variables if that helps.

Ping

Fix comment grammar.

I don't have commit access, could you commit this for me?

I don't have commit access, could someone commit this for me?