BTW as discussed earlier they are moving to patch points and a stack map but its not 100% what GCs are after but is gettng closer here is the patch of the proposal / spec doc
http://llvm-reviews.chandlerc.com/file/data/nzgudmvz4suiwnebe35b/PHID-FILE-hyesekt5ccgmx3i55uk6/D1981.id5090.diff Ben On Mon, Nov 11, 2013 at 11:19 AM, Ben Karel <[email protected]> wrote: > A front-end can maintain the invariant that every root which might have > been modified by a copying collector is reloaded from its associated root > slot. If it does so, then the GEPs introduced by internal optimizations > will be rendered harmless by LLVM's (core, non-GC-related) semantics. > > > On Sun, Nov 10, 2013 at 9:49 PM, Patrick Walton <[email protected]>wrote: > >> On 11/11/13 1:00 AM, Jonathan S. Shapiro wrote: >> > 2. LLVM won't introduce new getelementpointer operations internally, and >> > the front end is responsible for dealing with liveness issues for >> > element pointers introduced by the front end. >> >> Internally LLVM optimization passes can create the equivalent of >> arbitrary new GEP instructions during codegen. So a moving GC will not >> be able to find all pointers to relocate them. >> >> Patrick >> >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev >> > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
