Yes, r337329 did.

• cosmetic change

@jgravelle-google ping

• Type fix

• Type fix

For the same reason described here, in truncation/extension involving i64, we currently are not able to use the truncate/extend version of the cmpxchg instruction, so it is little suboptimal. Will solve this in a separate CL.

Ping

I'm OK with this, but @dschuff might prefer the library approach..?

• test fix

• Add a TODO

• Address comments
• Add +mattr=exception-handling flag

Currently LLVM treats all atomic IR instructions as volatile. Link0 Link1 So I'm not exactly sure what you mean by 'upgrade volatile to seq_cst' is. For non-atomic volatile memory instructions, they are not atomic, so they don't have orderings.

I think this CL can be reviewed as is. I will add an optimization for the success flag thing in another CL bc it is gonna be too long. So the problem I was talking about is, let's say we have these two test cases:

define i64 @cmpxchg_i8_i64_loaded_value(i8* %p, i64 %exp, i64 %new) {
  %exp_t = trunc i64 %exp to i8
  %new_t = trunc i64 %new to i8
  %pair = cmpxchg i8* %p, i8 %exp_t, i8 %new_t seq_cst seq_cst
  %old = extractvalue { i8, i1 } %pair, 0
  %e = zext i8 %old to i64
  ret i64 %e
}

Variable name change

1. For emscripten-based EH, we don't use a separate libcxxabi; emscripten provides handful of library functions in JavaScript. Are you planning to provide them from emscripten and import them from wasm?
2. Because now this does not create those functions and global variables anymore, certain tests, such as lower-em-exceptions.ll, will fail. I guess you should update that as well.

Turns out this is not currently able to make use of truncating/extending instructions when the 'success flag' of the LLVM IR cmpxchg instruction is used.

Tests for weaker memory orderings have been added in D49194.

Will add non-seq_cst tests in another CL, because I guess we need them in not only here but in atomic loads/stores too.

• Fix a typo

• Pattern name change: anyext_aload -> sext_aload

This pattern doesn't cover all the sign extension selection (we need a
sext_inreg after that), but it looks less confusing and more consistent with
zext_aload patterns. And we gave enough explanations in comments anyway.

• More unit -> region

• SortUnit -> Region

Why is this WIP and when do you plan to land this? I'm working on tests that may conflict with this, so I'm not sure which format I should target.

So after this patch, is the former register-based form of printing still supported, or the stack-baed form is the only printable form?

• blank lines

• Removed VT

• Revive -elf.. this is getting removed in D48744

• Remove -elf triple which is not needed anymore

• Revive vector_sdiv.ll and changed its name to vector-sdiv.ll
• Update comments

Oh, what I meant by the test started failing is not about rL335821 but rL335727. I wasn't even aware of getSetCCResultType thing when I posted the previous comment.. Anyway then I'll update the comment.

Thanks. I'm little not sure if you remember the history, so FYI, this test case was added in D46161 (rL329525) to make sure the case with 1's in a vector should NOT be converted to 'shr's and remain as 'sdiv's, in which case shifting a value by the number of its bit widths becomes undef. But after rL335727, you fixed it so now even vectors with 1's in there can be correctly treated as pow2 non-splat vectors, so this test started failing. So in rL335771 someone else (not me) fixed the expectation to 'shr's, so the purpose this case was added is now unnecessary.

Continuing the discussion started in the email:

@majnemer I inserted a routine to ensure a terminate pad should be a single BB in this previous pass (D46803). Do you have any other concerns here?