search for: normal_dest

For anyone following along on ToT using the gc.statepoint mechanism, you should know that ToT is currently not able to express arbitrary exceptional control flow and relocations along exceptional edges. This is a direct result of moving the gc.statepoint representation to using a token type landingpad. Essentially, we have a design inconsistency where we expect to be able to

...nsic with branches, because it's opaque to the > optimizer. > This statement is true at the moment, but it shouldn't be. I think this is our fundamental difference in approach. You should be able to write something like: i32 %res = invoke patchpoint (... x86_trapping_divide, a, b) normal_dest invoke_dest normal_dest: ;; use %res invoke_dest: landingpad ;; dispatch edge cases ;; this could be unreachable code if you deopt this frame in the trap handler and jump directly to an interpreter or other bit of code A patchpoint should not require any excess spilling. If values...

...cause it's opaque to the optimizer.  >  > This statement is true at the moment, but it shouldn't be. I think this is  > our fundamental difference in approach.  >  > You should be able to write something like:  > i32 %res = invoke patchpoint (... x86_trapping_divide, a, b) normal_dest  > invoke_dest  >  > normal_dest:  > ;; use %res  > invoke_dest:  > landingpad  > ;; dispatch edge cases  > ;; this could be unreachable code if you deopt this frame in the trap  > handler and jump directly to an interpreter or other bit of code  >  > I see. It soun...

...izer. >>> >> This statement is true at the moment, but it shouldn't be. I think >> this is our fundamental difference in approach. >> >> You should be able to write something like: >> i32 %res = invoke patchpoint (... x86_trapping_divide, a, b) >> normal_dest invoke_dest >> >> normal_dest: >> ;; use %res >> invoke_dest: >> landingpad >> ;; dispatch edge cases >> ;; this could be unreachable code if you deopt this frame in the >> trap handler and jump directly to an interpreter or other bit of code...

...This statement is true at the moment, but it shouldn't be. I think >> this is >> > our fundamental difference in approach. >> > >> > You should be able to write something like: >> > i32 %res = invoke patchpoint (... x86_trapping_divide, a, b) >> normal_dest >> > invoke_dest >> > >> > normal_dest: >> > ;; use %res >> > invoke_dest: >> > landingpad >> > ;; dispatch edge cases >> > ;; this could be unreachable code if you deopt this frame in the trap >> > handler and jump di...

...s, because it's opaque to the optimizer. > > This statement is true at the moment, but it shouldn't be. I think this is > our fundamental difference in approach. > > You should be able to write something like: > i32 %res = invoke patchpoint (... x86_trapping_divide, a, b) normal_dest > invoke_dest > > normal_dest: > ;; use %res > invoke_dest: > landingpad > ;; dispatch edge cases > ;; this could be unreachable code if you deopt this frame in the trap > handler and jump directly to an interpreter or other bit of code > > I see. It sounds...

On 04/29/2014 10:44 AM, Filip Pizlo wrote: > LD;DR: Your desire to use trapping on x86 only further convinces me > that Michael's proposed intrinsics are the best way to go. I'm still not convinced, but am not going to actively oppose it either. I'm leery of designing a solution with major assumptions we don't have data to backup. I worry your assumptions about