Fix effect analysis in presence of tail calls within try blocks

[vouillon]

This is obviously correct: this accounts for the fact that tail calls can throw through exception handlers.

It is probably not worthwhile to make a more precise analysis:

• The change only affects code with a tail call within a try block, which should be rare
• Tail calls already have a branchesOut effect, which greatly limits possible optimizations

[kripken]

Another option we discussed before was something like this:

1. Track a new field on EffectAnalyzer, hasThrowingReturnCall.
2. Set hasThrowingReturnCall in any return call, except for a direct call to a target we know cannot throw.
3. In walk(Function* func) - the walk for an entire function body - if at the end we have hasThrowingReturnCall then set throws_.

That seems like it would be as precise as we can get it, but as you said, it might not be worth the overhead. Maybe it's worth mentioning as a possible future TODO though. I'm curious what other people think here.

[tlively]

I prefer the approach @kripken sketched because any local optimizations around the return call should be able to rely on the fact that it will not throw, at least not in a way that is observable by surrounding code.

[vouillon]

To get a sense of how many optimizations we are missing, I have run wasm-opt -O3 on a 30 MiB binary with the following distribution of calls:

   1680 return_call_ref
   4316 call_ref
   4553 return_call
  17289 call

First with this PR, and a second time after modifying the code to (wrongly) assume that tail calls never throw:

       if (parent.features.hasExceptionHandling() &&
-          (parent.tryDepth == 0 || curr->isReturn)) {
+          (parent.tryDepth == 0 && !curr->isReturn)) {
         parent.throws_ = true;
       }

The output code was exactly the same in both cases.

[vouillon]

The output code was exactly the same in both cases.

Thinking a bit more about it, this is not that surprising. The only optimizations for which this makes a difference are the ones that eliminates a try block whose body does not throw (vacuum) or that moves code into (simplify-locals) or out of (code-folding) a try block.

Since my code does not contain any tail-call inside a try block, only the simplify-locals pass might make a difference. But the code has to be a bit convoluted for this to happen.

[kripken]

@vouillon to avoid duplicate effort, note that #6470 implements the other idea.

[vouillon]

Superseded by #6470