Address review comments.

Ping.

Fix a mistake.

Add a test case. Thanks Craig.

Thanks @craig.topper

Rebase.

Thanks @MaskRay.

Address review comments.

Address review comment.

In D79760#2035739, @tentzen wrote:

right, I noticed that too and looked into it further..

It turned out that Windows 32-bit runtime expects post-ordering when looking for catch-handler, but sharing the code with 64-bit runtime when looking up EH State during DTor cleaning-up.
Thus, MSVC/X86 today actually fails on Test7 in ehthrow.cxx.

Incorrect Ctor/Dtor ordering is less significant than Catch handling. for now LLVM must be compatible with MSVC.
This also affects the other two targets on Windows; Arm32 & Arm64. I re-submitted a simper and more completed patch (in D79474), including test case for AArch64. will add one for Arm32 later..

In D79760#2034640, @andrew.w.kaylor wrote:

In D79760#2033081, @pengfei wrote:

@andrew.w.kaylor I tested for below 3 cases, and get the runtime result for them in different compilers.

What I was trying to say is that you should add a new LIT test case that corresponds to the failure in PR42266. But also, I think we need stronger checking of the correlation between the try map and the handler map. Currently the test is looking for a specific order of the states in the try map, but the handler map is using a wild card check -- "CHECK-NEXT: .long "?catch${{[0-9]+}}@?0?try_in_catch@4HA"" We should be verifying somehow that the states in the try map get connected to the correct handler, which involves matching the specific handler. Your change reversed the order of the try map, but appeared not to change the handler map. That's a problem. If the handler map didn't also change, the code would be wrong.

Now that I've seen the patch from @tentzen I am not convinced that there is a required difference between 64-bit and 32-bit. I could be wrong, but it looks like the 64-bit case is different because newer runtimes require it. It isn't clear to me whether the 32-bit runtime will work with the new format.

If D79474 works for the cases you're trying to fix (including the 32-bit case), I think it's a better solution.

In D79760#2033315, @tentzen wrote:

I meant did you debug into the crash of your test case in https://bugs.llvm.org/show_bug.cgi?id=42266 ?

Copy the symbol only. Thanks @craig.topper 's suggestion and @chandlerc 's interpretation.

In D79760#2033169, @tentzen wrote:

Hi, Pengfei,
Did you get to the root of the bug and check the correctness of ctor&dtor ordering on your test cases?
Or you just tried to copy MSVC?

In D79760#2033052, @tentzen wrote:

Hi, Pengfei,
Is this the same bug as this patch, https://reviews.llvm.org/D79474/new/ , right?

@andrew.w.kaylor I tested for below 3 cases, and get the runtime result for them in different compilers.

void ex1() {
  try {
    throw 1;
  } catch (...) {
    try {
      throw 2;
    } catch (...) {
    }
  }
}
void ex2() {
  try {
    try {
      throw 1;
    } catch (...) {
      throw 2;
    }
  } catch (...) {
  }
}
void ex3() {
  try {
    throw 1;
  } catch (...) {
    try {
      try {
        throw 2;
      } catch (...) {
        throw 3;
      }
    } catch (...) {
    }
  }
}

In D78471#2032415, @craig.topper wrote:

Is the problem here really that foldMemoryOperand doesn't know to preserve the post instr symbol?

Rebased.

In D78471#2030719, @craig.topper wrote:

Can you pre-commit the test with the current codegen to show the problem this patch fixes?

Ping again. This is a bug fix. If no one opposes, I'll submit it to LLVM.

Ping.

It's better to add NFC in the title.
The type of TSFlags is uint64_t instead of const uint64_t, is it possible this value been changed during function call?

In D76190#1948762, @MaskRay wrote:

@pengfei You can strip unneeded Phabricator tags with:

% which arcfilter
arcfilter () {
        git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:$/ {sub(/^Summary: /,
"");print}' | git commit --amend -F -
}

Subscribers: and Reviewers: are just annoying. It is also not appropriate to use Patch By: Xiang Zhang (xiangzhangllvm). See https://llvm.org/docs/DeveloperPolicy.html#commit-messages " git commit --amend --author="John Doe <jdoe@llvm.org> to correct the author property"

Doesn't the modifier {z} clean the upper 64 bits?

LGTM.

Agreed, LGTM.

Address review comment.

Rebase and add vector instructions test.

In D72824#1835568, @RKSimon wrote:

Add to isNegatibleForFree/getNegatedExpression as well?

Remove unnecessary comment.

Address review comments.

Removed the FP_CONTRACT support code.

Add FMA4 tests. Thanks @RKSimon.

Address review comment.

Address review comments.

Remove dead code.

Yeah, it's useful and clear to use a STRICT_FP_EXTEND. Anyway, I think we can also achieve it by getting the function's attribute or propagating the fpexcept to FP_EXTEND.

Do we really need to distinguish STRICT_FP_EXTEND and FP_EXTEND for a return? Currently the STRICT nodes are used to avoid to be optimized out or reordered. But I think neither occurs for a return.

LGTM.

Add Fixme for softenSetCCOperands. We don't want to add extra logic code instead of pushing the libraries to do the right thing.
Address review comment.