sure - I'll try to add some documentation of IPA, probably directly inlined into the code. Unfortunately, a too verbose dev documentation quickly gets outdated because nobody updates it - let's see if we find the sweet spot that works for the project.
Regards, Matthias On Wed, Jun 14, 2017 at 4:15 PM, <[email protected]> wrote: > Agreed. More documentation, especially within the optimizer portion of > the engine, is quite useful. Given that a large number of our bugs and > performance issues stem from this area, it would be good for it to be clean > and well documented so that future bug searches/fixes can be completed in a > more expedient manner. > > -- > > Mike Dusenberry > GitHub: github.com/dusenberrymw > LinkedIn: linkedin.com/in/mikedusenberry > > Sent from my iPhone. > > > > On Jun 14, 2017, at 8:51 AM, Nakul Jindal <[email protected]> wrote: > > > > Hi Matthias, > > > > If its not too much trouble, could you please create a design document > for > > this change. > > This will help the rest of the contributors work on this component as > well. > > > > Thanks, > > Nakul > > > > > > On Wed, Jun 14, 2017 at 12:00 AM, Matthias Boehm <[email protected] > > > > wrote: > > > >> just a quick heads up: in the next couple of days, I'll rework our > existing > >> inter-procedural analysis (IPA) in order to (1) create well-defined IPA > >> passes, (2) reuse functional call graphs across multiple rounds of IPA, > and > >> (3) introduce new IPA passes such as fine-grained literal propagation > and > >> replacements as well as inlining of functions with control structures. > This > >> will help improve the performance and debugging of scripts with complex > >> function call patterns. However, since this is a rather disruptive > change, > >> we might experience temporarily some compiler issues - if that happens > >> please file anything you encounter against SYSTEMML-1668. > >> > >> Regards, > >> Matthias > >> >
