On Feb 8, 2013, at 12:07 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 11:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > At build time the user may say I know this, this and this. Those get > compiled in. They then use the built thing for a while and are free to set at > runtime any of the other many options that were not compiled in. > > How would they specify what they want to use? Hopefully using the options > database. Of course. > > Inlining could then be thought of as an extreme case of profile-guided > optimization, in the sense that you run an instrumented instance of the code > to determine which decisions have been made, then recompile (mostly just > fusing the right things) and Yup. > > > > Or are you just JITing and caching the result of the JIT pass in a > > "library" that you'll keep around for a while (maybe several separate runs) > > before it gets gc'd? > > So yes it is JIT like, if you will. The point is that conceptually "JIT" > is/can be a spectrum of possibilities and should be treated that way. > Developers shouldn't need a different process or mindset because it is "JIT" > or not. > > You're going to have to annotate/teach/declare what should be jitted. My > JIT-based suggestion is mostly about using a special mechanism for assigning > and calling those chaseable pointers, so that they could be resolved later > using the JIT.
