[CIR][CodeGen] Add initial support for __cxa_rethrow

[bruteforceboy]

This PR adds an initial support for __cxa_rethrow, and one test that produces a rethrow.

I am very open to suggestions regarding this PR, because I'm still a bit unsure if this replicates the original codegen properly. For example, using the test added, the OG CodeGen produces:

entry:
  invoke void @_ZN1SC2Ev(ptr noundef nonnull align 1 dereferenceable(1) %s)
          to label %invoke.cont unwind label %lpad

invoke.cont:                                      ; preds = %entry
  invoke void @__cxa_rethrow() #2
          to label %unreachable unwind label %lpad

lpad:                                             ; preds = %invoke.cont, %entry
  %0 = landingpad { ptr, i32 }
          catch ptr null
  %1 = extractvalue { ptr, i32 } %0, 0
  store ptr %1, ptr %exn.slot, align 8
  %2 = extractvalue { ptr, i32 } %0, 1
  store i32 %2, ptr %ehselector.slot, align 4
  br label %catch

catch:                                            ; preds = %lpad
  %exn = load ptr, ptr %exn.slot, align 8
  %3 = call ptr @__cxa_begin_catch(ptr %exn) #3
  %4 = load i32, ptr %r, align 4
  %inc = add nsw i32 %4, 1
  store i32 %inc, ptr %r, align 4
  call void @__cxa_end_catch()
  br label %try.cont

and the proposed CIR equivalent produces:

  invoke void @_ZN1SC2Ev(ptr %1)
          to label %5 unwind label %9

5:                                                ; preds = %4
  invoke void @__cxa_rethrow()
          to label %6 unwind label %13

6:                                                ; preds = %5
  br label %7

7:                                                ; preds = %6
  unreachable

8:                                                ; No predecessors!
  br label %22

9:                                                ; preds = %4
  %10 = landingpad { ptr, i32 }
          catch ptr null
  %11 = extractvalue { ptr, i32 } %10, 0
  %12 = extractvalue { ptr, i32 } %10, 1
  br label %17

13:                                               ; preds = %5
  %14 = landingpad { ptr, i32 }
          catch ptr null
  %15 = extractvalue { ptr, i32 } %14, 0
  %16 = extractvalue { ptr, i32 } %14, 1
  br label %17

17:                                               ; preds = %13, %9
  %18 = phi ptr [ %11, %9 ], [ %15, %13 ]
  %19 = call ptr @__cxa_begin_catch(ptr %18)
  %20 = load i32, ptr %2, align 4
  %21 = add i32 %20, 1
  store i32 %21, ptr %2, align 4
  call void @__cxa_end_catch()
  br label %22

There are quite a number of differences: phi in the CIR version VS loading from %exn.slot in the OG, having multiple landing pads, etc.

The CIR version still seems reasonable to me, mostly because currently we are unable to replicate the exact behavior of the OG codegen. Again, I am very open to more discussions and suggestions here)

[bcardosolopes]

Overall this looks good, some minor change needed.

There are quite a number of differences: phi in the CIR version VS loading from %exn.slot in the OG, having multiple landing pads, etc.

Yes, we use block arguments for the slots, and don't unique landing pads (yet). We might stay with the former but fix the later.

The CIR version still seems reasonable to me, mostly because currently we are unable to replicate the exact behavior of the OG codegen. Again, I am very open to more discussions and suggestions here)

I think it's similar enough!

[bcardosolopes]

We just went over a rebase against upstream, apologies for the churn but please update your branch for this PR and force-push!

[bcardosolopes]

Awesome, thanks!

[bruteforceboy]

@bcardosolopes thanks for approving!

I am still a bit worried about the case where we ignore everything below the UnreachableOp (conversation for reference). I currently have a code snippet where I have some operations below the rethrow and this PR doesn't work quite fine.

You mentioned that it is a bigger problem in CIR. So, I am just curious what will be to correct way to fix this? Is there something wrong with the approach using blocks? I can open a new PR or modify this, but I want to know the right way to approach this.

[bcardosolopes]

I am still a bit worried about the case where we ignore everything below the UnreachableOp (conversation for reference). I currently have a code snippet where I have some operations below the rethrow and this PR doesn't work quite fine.

I'm worried too, thanks for followin up with that!

You mentioned that it is a bigger problem in CIR. So, I am just curious what will be to correct way to fix this? Is there something wrong with the approach using blocks? I can open a new PR or modify this, but I want to know the right way to approach this.

A new PR would be great! Manipulating blocks sounds fine, we can go over specific concerns over reviews.