[PATCH] D86673: [StackColoring] Conservatively merge Variable in catch(Variable)

[Than McIntosh via Phabricator via llvm-commits]

thanm added a comment.

In your C++ test case, you write this:

  // "exp" is written by the OS when the "throw" occurs.

however when I compile the testcase as instructed I see the following entry block:

  define dso_local i32 @main() local_unnamed_addr #1 personality i32 (...)* @__CxxFrameHandler3 {
  entry:
    %tmp.i.i = alloca i32, align 4
    %o.i = alloca %struct.object, align 4
    %exp.i = alloca i32*, align 4
    %0 = bitcast i32** %exp.i to i8*
    call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %0)
    %1 = bitcast %struct.object* %o.i to i8*
    call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %1) #3
    %i.i.i = getelementptr inbounds %struct.object, %struct.object* %o.i, i32 0, i32 0
    store i32 1, i32* %i.i.i, align 4
    %2 = bitcast i32* %tmp.i.i to i8*
    call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %2)
    store i32 999, i32* %tmp.i.i, align 4
    invoke void @_CxxThrowException(i8* nonnull %2, %eh.ThrowInfo* nonnull @_TI1H) #4
            to label %.noexc.i unwind label %ehcleanup.i

If as you say the OS writes to "%exp.i", then this should be reflected in the IR in the entry block -- the call/invoke should include a reference to the thing that potentially gets written. Otherwise it's hard to see how optimization passes can safely work on the IR.

Suppose this was a C program and the code looked like

  int myfunction() {
    char b[128];
    somefunction();
    ... 
    b[0] = ...
  }

You are effectively saying "When the call to 'somefunction' happens, the OS may write to 'b'", even though the address of 'b' is not used until much later in the function.

This doesn't make sense -- what would be better is to have the IR reflect realitty, e.g. that the address in question has effectively escaped, and thus it can be written at calls, etc.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86673/new/

https://reviews.llvm.org/D86673