Re: Link-time optimzation

[Andrew Pinski <pinskia at physics dot uc dot edu>]

Some more comments (this time section by section and a little more thought out):

2.1: 
Requirement 1: a good question is how does ICC or even XLC
do this without doing anything special? Or do they keep around
an "on-the-side" database.

(Requirements 2-4 assume Requirement 1)

Requirement 5: is perfectly fine as far as I can tell.

(Requirement 6 assume Requirement 1)

Requirement 7: seems prefectly fine, maybe going more
into which are incompatible options, -ftrapv is a good
example, -fwrapv is another very good example.

2.2:
Requirement 8-10: prefect.

2.2.1:

Maybe I am missing something but I don't see where common
symbols are mentioned.  Are they really just weak?

2.2.2:

So are pointer pointing to type1 the same type as reference
pointing to type1?  The way I read the document, pointers and 
references are interchangable.  Maybe an explited statement
saying they are the same type or not.

(3: all assume requirement 1.)

3.2: does that mean GCC would begin using BFD also or I am
reading that wrongly? Or we are could read in all file formats
using a new interface which mean we duplicated all the BFD reading
code.

A good question about this whole 3 section is how does ICC or XLC
handle this.  I understand we don't want to repeat their mistakes
but not mentioning what they do seems like it was not as thought
through as it really was.

4:

Requirement 11: Very good.

Requirement 12: I still am secticial of all these source-anaylsis
programs.  Now export is a different reason, but the problem
with using the rest of the requirements for this is wrong as
first there is no way to repesent overloaded sets, all the C++
specific code (though we could extend the bytecode but is harder
if we don't design it in the first place).


Requirement 13 and 14: are no brainers.

Just one note about 14, stack based bytecode does not correspond
to GIMPLE TREE representive that well.  An infinite register
one with no stack except for ADDRESSABLE variables.

Also the Rationale of 14 says we go in and out of SSA, is that expensive?
for an example PHI insertion is O(N log(N)), see PR 18594 for an example
of where this can take a long time.


4.1: assumes requirement 1.
Yes dwarf3 is well defined but has it really ever been used for this
purpose before, that seems like a question which should be answered here.

4.2: semi does not statifies requirement 14, see above.

There should be mention of other bytecodes so it does not look like only
those two were looked at since there are some major ones like LLVM which
is gaining a huge movement inside Apple for an example.  WIRL is another
one which comes to my mind.

the registers: 
  The registers of the GVM correspond one for one with the local 
  variables at the GIMPLE level.

>From reading that, does that mean we actually have all variables in
registers and that the stack is not that useful?

An example of what the bytecode would look like with that saying is:
push a
push b
add
pop c

which is the same as c = a + b.  Are in a non stack based bytecode:
add c, a, b
Just like a three operand ISA.

But doesn't that mean we really have a non stack based bytecode with
just instructions which act on the stack and that stack will be
empty after one GIMPLE instruction is executed?  Then why have a 
stack at all as no part of the compiler as far as I can see will
ever generate code which does stuff like:
push a
push b
add
push c
add
pop d
Which is equivalent to d = (a+b)+c.

Now a pre-link time optimizer could do it if it can prove that the (a+b) is only used
that once.


What we would produce right now with gimple is:
e = a+b;
d = e+c;

Or to the stack bytecode:

push a;push b; add; pop e; push e; add; pop d;

But we need an extra pass to optimize away the pop/push if we are already out of SSA.


Now if the registers correspond to GENERIC variables, we would be
produce d = (a+b)+c;


-- Pinski