We know the shadow Stack alone costs about 6-7%. Any compiler will be less able to optomize derived pointers/ internal references so your never going to be at C level for these types of references . Vectors dont use GEP so we are dealing with embedded value types and embedded arrays though vectors may have a problem with derived pointers in a loop as well.
I also dont fully understand the cost of the LLVM root intrinsic , it states it leaves implimentation up to the GC stub which you can implement yourself ( but that derived pointers etc are not supported by LLVM) but thats where the documentation ends , i had a quick look through the code but need to look further..Will look further if i get a chance . Anyone know if its possible to make some dirty changes so these types are not so easily lowered to int values ? Ben On Mon, Nov 11, 2013 at 1:41 PM, Ben Karel <[email protected]> wrote: > Intuitively, yes, but how much is less clear. Do you have measurements > showing just the effect of the GC-related invariants in LLVM's current > setup? > > > On Sun, Nov 10, 2013 at 11:30 PM, Patrick Walton <[email protected]>wrote: > >> On 11/11/13 12:19 PM, Ben Karel 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. >> >> At the cost of performance. >> >> 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
