This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Temporarily enable ac_fold_checking for --enable-checking=yes.


On Sat, 2007-06-23 at 21:20 +0200, Eric Botcazou wrote:
> > I have two concerns.  First, I think some of the testing we do is not
> > delivering value proportional to cost.  Is 20061226-1.c (sp?) really
> > delivering anything close to the same percent of our quality that it
> > costs in testing?  If not, should we let it take up several percent of
> > our testing?
> 
> gcc.c-torture/compile/20001226-1.c to be precise.  FWIW, the first thing I do 
> before testing on SPARC machines is 'rm gcc.c-torture/compile/20001226-1.c'.
You do know there's a fundamental weakness in how reorg.c works that,
if fixed, should drastically reduce compile time for 1226-1.c on targets
with delay slots such as the sparc.

We've got some severe uglyness in how we scan for candidate insns, then
do resource checking to see if they're safe to move.  This would be much
better implemented using real dependency analysis.  For example, will
filling a slot from code before the branch, we should be looking at just
leaf nodes in the dependency graph for the block containing the branch.

Similarly when filling from the target, the only insns you should ever
consider are the roots of the dependency graphs in the target block.

There's other cases, but if delay slot filling were turned into a 
dependency problem I think a lot of its slowness and downright uglyness
goes away.

But attackign these problems are independent of attacking testing in
general.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]