Agenda (problems discussed, events to come): ============================================ - the nitty-gritty of our approach to RCG in Multiflow (Joel) - what happened since last week (everybody who did anything) - Multiflow source control (postponed till next week) - Cindy Collins visiting from Oregon (probably in a month) Renaming: ========= There was a little bit of confustion caused by different people using different terms to denote the same things. We decided to clear the issue and came up with the following replacements for old terms: template (used to be subtemplate) region (used to be template) run-time constant (used to be dynamic constant) static compile (denotes offline compilation process) dynamic compile (denotes online or run-time compilation process) Some details of our approach to TCG in Multiflow: ================================================= [I missed the beginning until I started taking notes] Loop unrolling at run-time -------------------------- To approaches to loop unrolling were proposed: - a framework that has example loops embeded in it and which detects which case of a loop a given one is, and acts appropriately, - a framework using simple partial evaluation to extract the right setup code and determine loop boundries, The first solution was given no attention because of its limitatiotions to a fixed set of loop shapes. We decided setup code copies ... some issues raised during the discussion: - we want examples of how the compiler should operate on some simple and complex loops - in some cases we one doesn't want to do loop unrolling at all. [some example?] To facilitate full control over loop unrolling we will provide pragmas to determine which loops should be unrolled and which not. - in general, at first stage, we want to be as little automatic as possible to be able to experiment and debug each part of the system separately and to measure the impact of each of them separately - in Multiflow, "continue" inside of a loop will cause the loop to be treated as two nested loops How to do barriers ------------------ - labels around end of the IF statement that splits into the setup and template code - how do we keep info on where the templates are - interactions with register allocation - code scheduling can move stuff around - do it as late as the graph exists - a virtual IF around the whole dynamic region and the setup code to make sure that the code is not moved outside of the region - should the trace scheduling be turned off on on inside of the dynamic regions? are there any adverse interactions? benchmarks ---------- - are we willing to make changes to test programs? what is we can get more provided we maddage the code a loittle bit?