i seem to have hit a problem with my new conflict finder.

[Kenneth Zadeck]

it looks like the backwards scan is not getting "enough" interferences
to make reload/global happy.

the case comes about because of way local_alloc is preassigning regs for
pseudos that would map into more than 1 hardreg.

pseudo's are as wide as they need to be.  When local_alloc assigns one
of these to a hard reg, it assigns it to the first hardreg needed and
the mode is used to indicate how many of the following regs are needed.

The problem comes where you have a store that uses 2 or more hard regs
but one or more of those hardregs is unused.

In a forwards scan, ALL of the set regs will interfere with anything
live until the last set reg goes dead.  In a backwards scan, the unused
hard regs never cause interferences.
global/reload wants these interferences.

This is, of course, one of the reasons that backward scanning the proper
way to build an interference graph.  But something in global or reload
cannot handle the truth.

There are a lot of ways to handle this problem:
1) We could do a pass that breaks multiword sets into individual regs if
some of those regs are dead.  I guess the downside of this is that such
insns may not match some patterns anymore.

2) We could turn off local.  I was planning on testing this anyway
because i want to see if local, at this point, is just making global do
a bad job.   However, my hope is that global or the new allocator from
vlad is smart enough to properly handle the case where some parts of a
multiword set are dead. 

3) We could fix global/reload to not be stupid.   Because, of course,
you should be able to put something in that unused regs slot. 

Any comments.

I am enclosing my patch, which is currently undertested.  I have not
bootstrapped it on any platform, but it currently is regression free on
x86-64 and the remaining bugs on ppc-32 may all be this one. 

The case i have been looking at is:

/valinorpublic/gbGlobal/gcc/xgcc -B/valinorpublic/gbGlobal/gcc/
/home/zadeck/gccGlobal/gcc/testsuite/gcc.c-torture/execute/20001203-2.c 
-w  -Os  -fno-show-column  -lm   -o
/valinorpublic/gbGlobal/gcc/testsuite/gcc/20001203-2.x5

which is nice and small.

Kenny 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nourec2.diff
Type: text/x-patch
Size: 71673 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070817/9192e383/attachment.bin>