I believe all the feedback has now been addressed.

• Use header guard macro instead of pragma

• Prefix identifiers with __
• Use specific bit-widths where possible
• Do not change semantics under -funsigned-char

• Update license to match xmmintrin.h format

Maybe add a comment saying why the new line is important.

Even without running V8 or some other external validator, I agree it's surprising that the change in section order did not cause any tests to change. I guess most of our tests just look at a single section rather than a sequence of sections? And most don't have an events section at all.

LGTM!

@aheejin I more or less rewrote this, so if you could take another look that would be great.

• Refactor and add better tests

• Address comments

• Address comments

In D73943#1858326, @dschuff wrote:

The langref says (https://llvm.org/docs/LangRef.html#call-instruction) that the tail call marker implies that the callee does not access allocas from the caller. So it seems like it *should* mean that the backend can depend on this property (that you're checking for here). It also means that the frontend should guarantee it as best it knows how, and optimizations should not introduce it (or remove the attribute if they do?)

Looks good to me! I don't have enough context to know of any other locations where this could be missed, so I'm not sure whether a helper function would be useful. It could always be added later, anyways.

In D74191#1865981, @aheejin wrote:

It looks this assumes D71484 and D71496 have not been reverted, right?

The Emscripten test suite passes with this change as well.

• Update whitespace in tests

I want to go through this and fix obvious white space errors in the tests, but the code should be good to go.

• Resolve small TODO

• Rebase on D74191

In D73943#1857542, @dschuff wrote:

It doesn't look like there's anything wasm-specific here. Surely this also inhibits tail calling in other backends too? Are frontends suppost to avoid putting 'tail call' in the IR in this case?

This patch is still mostly good, but it will have to be rebased on a different approach to supporting multivalue.

Sounds good to me!

LGTM! Tested locally and this fixes the problem.

@aheejin This should be properly rebased and ready for review as well. Sorry for all the messed up diffs!

• rebase