search for: reapplication

Looking back through the commits to llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h, I see a total backout of format related warnings in r56923 followed by the reapplication of r569065 with a fix (r56946)... -- llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/01 17:38:40 56923 +++ llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/02 06:16:08 56946 @@ -101,6 +101,8 @@ %{!mmacosx-version-min=*: %{!miphoneos-version-min=*: %(darwin_cc1_minversion)}} \ "/*...

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like below to ensure that only base pointers are live across statepoints when it's done (plus a bit of book...

...that we now need to be able to do this for correctness. -- Sanjoy Joseph Tremoulet wrote: > Sorry to reply to myself here, but I had an idea regarding "issue #2" > -- possibly what makes the most sense for those clients/targets is to > pull the pointer difference computation/reapplication into RS4GC > itself -- it could have a pass just before or after rematerialization, > which runs based on a configuration flag (eventually to be driven by > GCStrategy), which performs rewrites like below to ensure that only > base pointers are live across statepoints when it's...

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

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