Some thoughts and quetsions about the data flow infrastracture

Mark Mitchell mark@codesourcery.com
Tue Feb 13 04:45:00 GMT 2007


Vladimir N. Makarov wrote:

>> However, my understanding (as someone who's not an expert on the DF code
>> base) is that, as you say, the new stuff is much tidier.  I understood
>> the objective to be not so much that DF itself would directly improve
>> the generated code, but rather than it would provide much-need
>> infrastructure that would allow future improvements.  This is a lot like
>> TREE-SSA which, by itself, wasn't so much about optimization as it was
>> about providing a platform for optimization.

> Imho, it is not a right analogy.  The right analogy would be a new RTL
> (low-level IR).  I know insn scheduler and RA well and I would not
> exaggerrate the DF importance such way at least for these tasks.

I was not trying to suggest that DF is necessarily as sweeping a change
as TREE-SSA.  Certainly, it's not a completely change to the
representation.

The sense in which I meant to suggest similarity is that DF is
infrastructure.  It's not that DF is a new optimization; it's that it's
a facilitator of optimizations.  The point is to get more accurate
information to the various RTL passes, in a more consistent way, so that
they can do their jobs better.  And, to be able to adjust those patches
to use newer, better algorithms, which depend on easy access to dataflow
information.  And, perhaps, to permit the creation of new optimization
passes that will only be useful because more accurate information is
available.

My point is that I don't think that the right criteria for DF is whether
it makes the generated code faster.  So long as it doesn't make the
generated code slower, and so long as the APIs seem well designed, and
so long as it doesn't make the compiler itself too much slower, I think
it's a win.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc mailing list