On Thu, Apr 7, 2011 at 7:59 AM, Ben Karel <[email protected]> wrote: > On Mon, Apr 4, 2011 at 8:42 AM, Ben Kloosterman <[email protected]>wrote: > >> I will second that the whole shadow stack is a bad approach from the >> start , it needs a redesign. Eg apps can emit GC code snippets , while not >> too difficult to do it’s a architectural change which requires more from >> application and hence some politics.. >> > > Wait, who said anything about a shadow stack? >
Last time I looked, the basic GC model in LLVM was to use a shadow stack, and LLVM lacked the necessary infrastructure to build, e.g., call frame register maps. > ...it's not a question of [the LLVM team] sticking their heads in the > sand about GC, it's simply that the core clients (and sponsors) of LLVM are > for non-GCed languages. So they are rationally allocating their resources > towards improvements that benefit all LLVM clients, and assuming that those > clients who are not satisfied with the current infrastructure will improve > it as they find necessary. > Compiler infrastructures take a long time to build, and are long term investments. They involve core technical decisions that are *very* difficult to change (e.g. the IR design). For this reason, successful compiler infrastructures simply cannot afford to succumb to the kind of short-term thinking you espouse. In this case, the core technical decisions in question go all the way back to Chris's Masters work, so I have to say that I don't buy the sponsorship argument. In any case, if the LLVM team believes that a sufficiently motivated party can do an incremental evolution from where they are to a GC-supporting IR, I think they are being unreastic. It isn't a simple set of changes. The level of disruption to currently ongoing work in progress is simply too high, the negative performance impact is likely to be significant, short-term sustained competitiveness mitigate against both. Chris is not the least bit naive about these concerns. I find the LLVM infrastructure to be a disappointment from this perspective. Given how recently it was designed, and the clearly desperate need to deal with mixing managed and non-managed languages, the decision to omit core support for managed languages from the LLVM design strikes me as a bad design decision. Micrsoft has definitely gotten this right; I think Apple has not. The decision to *implement *LLVM in a non-managed language also strikes me as ill chosen, though that decision more sense to me situationally. Apple has a significant commitment to Objective-C. The absence of a precise GC for Objective-C is both well-known and a significant impediment to Objective-C developers. For Apple, of all companies to produce at this time a compiler infrastructure that fails to support Objective-C as a first-class language is something that should have companies whose products are committed to Objective-C dusting off their migration plans. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
