Invoke instructions kick us off the FastISel path

[pcwalton]

We are never on the fast instruction selection path in LLVM because we're using Invoke instructions everywhere. Thus we pay the cost of full optimized SelectionDAG invocation at all optimization levels in rustc.

The solution is to stop using C++ exceptions for unwinding.

[brson]

It is probably not very difficult to switch the landing pads to use the function return value. Initiating unwinding could be done with a tiny intrinsic.

Since we would be returning through __morestack normally the reset_stack_limit upcall would no longer be needed, reducing bloat. This will make stack management code in task_start_wrapper simpler for similar reasons.

The trickiest part may be handling an out-of-stack failure but fortunately we seem to be doing it wrong now anyway (#3555). __morestack can be changed to check the return value of upcall_new_stack for null and return early, but it will leak the arguments.

[pcwalton]

We are also getting kicked off the FastISel path for two other reasons: (a) intrinsic function calls that LLVM doesn't know about; (b) invalid types (first class aggregates?) Investigating.

[pcwalton]

Oh, bah. It's the memmove. FastISel wants memcpy.

[pcwalton]

Slices treated as immediates ({ i8*, i64 }) cause FastISel bailouts as well. Paging @nikomatsakis because we probably need to figure out how to make these datums into non-immediates.

[nikomatsakis]

I'm surprised that they are being treated as immediates. First place to look is type_is_immediate()---otherwise, it must be some specific code path that is causing them to get treated by value (e.g., a ++ mode argument).

[graydon]

non-critical for 0.6, de-milestoning

[pcwalton]

Still true, still sad. Return-unwind fixes this.

[thestinger]

@pcwalton: it seems like the compiler doesn't generate memmove instructions itself anymore. So at least that part is solved.

[thestinger]

This is still a problem but the number of landing pads has been greatly reduced.

[alexcrichton]

This is quite an old bug, and I believe that quite a bit of work has gone into improving this since it was opened. We still have invoke instructions, but they're necessary for the current unwinding strategy. Alterations to the unwinding strategy should now be discussed in the RFC repo rather than here, and other than that I believe this is not necessarily actionable any more, so closing.