Mirsad Todorovac wrote:
At compile time heuristics determine whether routine fits the criteria for making two versions of it and doing sort of "run-time smart virtual range-checking and linking" (:-) at least it sounds good).
But, then again, it's PHASE 3. First comes PHASE1, to introduce solid range-checking and make it work. Optimizations probably come as PHASE 2, and proposed "dynamic routine version choosing" last.
Yes, though I don't think phase 3 is realistic at all. There's a number of problems: Currently, GPC generates tree nodes while parsing. If you wanted to get a second version of the loop, you'd either have to re-parse things (not too easy to rewind the parser correctly in all situations), or to copy the generated tree(s) and modify it. But since things are different, this might not work (since the one loop is supposed to be simpler than the other one, they'll have to contain partly different elements).
Besides this practical problem, there are also principle problems: What if a there's a label in the duplicated loop? What if such loops are nested, are you going to have 4, 8, 16, ... versions? ;-) And debugging is also a problem. If the user sets a breakpoint in the first copy of the loop, he might be surprise because the other one is executed and the breakpoint never reached. ;-)
So I doubt whether that's so useful. I guess in many situations the code overhead (if most of all `for' loops are copied) is not worth the speed gain (since probably most loops are not time-critical, anyway). So the programmer should deal with those that really are and declare type accordingly, turn off checking locally, or if he *really* needs this, create two copies himself.
You don't have to know about the intermediate forms ("tree nodes" and "rtl"). Just describing things in terms of Pascal (or C) code should be enough -- we can translate it into tree nodes then.
Is there a way to generate text file with this rtl intermediate representation, to see what's going on? Maybe it could be clearer to read than assembler(s)?
With the option `--debug-gpi', GPC will write the tree nodes while stored in/loaded from GPI files (unit/module interfaces) -- beware, this usually gives huge amounts of output, so you better redirect it (stderr) to a file or pipe it through less ...
This is only the interface, but it's possible to dump other tree nodes like this. The output is generated by debug_tree (called in module.c) and to see other tree nodes, you can insert such calls in other places in the GPC source.
Frank