emscripten-fastcomp - LLVM with the emscripten fastcomp javascript backend

Age	Commit message (Collapse)	Author
2013-03-22	Update test. There may be multiple catches, but those will be cleaned up.	Bill Wendling
	git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177758 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-22	Use references to attribute groups on the call/invoke instructions.	Bill Wendling
	Listing all of the attributes for the callee of a call/invoke instruction is way too much and makes the IR unreadable. Use references to attributes instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175877 91177308-0d34-0410-b5e6-96231b3b80d8
2011-09-02	Update to new EH scheme.	Bill Wendling
	git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138989 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-27	Auto upgrade the old EH scheme to use the new one. This is on a trial basis. If	Bill Wendling
	things to disasterously over night, this can be reverted. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138702 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-09	SplitCriticalEdge can sometimes split the edge from an invoke to a landing	John McCall
	pad, separating the exception and selector calls from the new lpad. Teaching it not to do that, or to properly adjust the CFG afterwards, is out of scope because it would require the other edges to the landing pad to be split as well (effectively). Instead, just recover from the most likely cases during inlining. The best long-term solution is to change the exception representation and commit to either requiring or not requiring the more complex edge-splitting logic; this is just a shorter-term hack. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132799 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-01	First, do no harm -- even if we can't find a selector for an enclosing	John McCall
	landing pad, forward llvm.eh.resume calls to it instead of turning them invalidly into invokes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132382 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-30	Add the test case for phis in the outer landing pad during the inliner's	John McCall
	forwarding of eh.resume that I promised yesterday. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132307 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-28	Implement and document the llvm.eh.resume intrinsic, which is	John McCall
	transformed by the inliner into a branch to the enclosing landing pad (when inlined through an invoke). If not so optimized, it is lowered DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume as appropriate). Its chief advantage is that it takes both the exception value and the selector value as arguments, meaning that there is zero effort in recovering these; however, the frontend is required to pass these down, which is not actually particularly difficult. Also document the behavior of landing pads a bit better, and make it clearer that it's okay that personality functions don't always land at landing pads. This is just a fact of life. Don't write optimizations that rely on pushing things over an unwind edge. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132253 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-27	Fix the inliner to maintain the current de facto invoke semantics:	John McCall
	- the selector for the landing pad must provide all available information about the handlers, filters, and cleanups within that landing pad - calls to _Unwind_Resume must be converted to branches to the enclosing lpad so as to avoid re-entering the unwinder when the lpad claimed it was going to handle the exception in some way This is quite specific to libUnwind-based unwinding. In an effort to not interfere too badly with other unwinders, and with existing hacks in frontends, this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does nothing with selectors if it cannot find a selector call for either lpad. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132200 91177308-0d34-0410-b5e6-96231b3b80d8