Mainline space problem

Mainline space problem

[Bradley Lucier]

Right now, the bug in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852

is making it more difficult for me to test the correctness of the 
generated code.  (I know the code's not correct, but I'm trying to find 
a suitable test case to diagnose, and that's hard when some of the 
modules don't even compile because cc1 requires more than 2GB of RAM.)

It would be nice if someone could try to fix the problem here.  I don't 
know why it's still marked as UNCONFIRMED when Andrew has noted the 
precise allocation that fails.

Brad

Re: Mainline space problem

[James E Wilson]

Bradley Lucier wrote:
> It would be nice if someone could try to fix the problem here.  I don't 
> know why it's still marked as UNCONFIRMED when Andrew has noted the 
> precise allocation that fails.

The problem Andrew pointed out isn't something that can be fixed. 
global builds a conflict matrix that is quadratic in number of pseudos. 
  So if you have 100K+ pseudos, then you need 2GB+ of memory.  This 
can't be fixed, at least not in global.

The only way to solve this is to try to reduce the number of pseudos 
created.  As this testcase has a very large function that uses a lot of 
&&label extensions, coding this differently would help, though I realize 
this may not be feasible.  Since we already have 100K+ pseudos in the 
.rtl dump, and they all appear to be used, there is probably nothing we 
can do in the RTL optimizer.  So the only option would be to look for a 
way to throttle the tree/gimple optimizer to avoid over optimizing very 
large functions to the point where gcc will run out of memory.  This 
isn't a very interesting task for a volunteer.

Since you care more about this problem than anyone else at the moment, 
you might try tracking down the problem a bit more.  If the testcase 
really did work two months ago, then you might be able to find a patch 
that broke it.  If you can do that, then you are more likely to find 
someone to look at the problem.  Otherwise, it isn't clear that anything 
broke.  This may just be a side-effect of the new tree/gimple optimizers.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Mainline space problem

[Daniel Berlin]

On Mon, 30 Aug 2004, James E Wilson wrote:

> Bradley Lucier wrote:
>> It would be nice if someone could try to fix the problem here.  I don't 
>> know why it's still marked as UNCONFIRMED when Andrew has noted the 
>> precise allocation that fails.
>
> The problem Andrew pointed out isn't something that can be fixed. global 
> builds a conflict matrix that is quadratic in number of pseudos.  So if you 
> have 100K+ pseudos, then you need 2GB+ of memory.  This can't be fixed, at 
> least not in global.

Only if the conflict matrix is
1. Dense.
2. Bidirectional.

Otherwise, you could use sparse bitmaps (in case of 1 not being gtrue) , 
and/or a lower-triangular bitmatrix (in case of 2 not being true).

Unless global is doing something completely weird (it may be, i haven't 
looked at since i worked on new-ra), the conflict matrix is unidirectional 
(IE if x conflicts with y, then y must conflict with x).
Thus you can use a lower-triangular bitmatrix, and save half the 
memory.
.
This is a standard technique for interference graphs in graph coloring 
register allocators.

See http://citeseer.ist.psu.edu/cooper88how.html
(It's a little out of date these days, but still goes over this stuff).

--Dan

Re: Mainline space problem

[Jeffrey A Law]

On Mon, 2004-08-30 at 21:31, Daniel Berlin wrote:
> On Mon, 30 Aug 2004, James E Wilson wrote:
> 
> > Bradley Lucier wrote:
> >> It would be nice if someone could try to fix the problem here.  I don't 
> >> know why it's still marked as UNCONFIRMED when Andrew has noted the 
> >> precise allocation that fails.
> >
> > The problem Andrew pointed out isn't something that can be fixed. global 
> > builds a conflict matrix that is quadratic in number of pseudos.  So if you 
> > have 100K+ pseudos, then you need 2GB+ of memory.  This can't be fixed, at 
> > least not in global.
> 
> Only if the conflict matrix is
> 1. Dense.
> 2. Bidirectional.
> 
> Otherwise, you could use sparse bitmaps (in case of 1 not being gtrue) , 
> and/or a lower-triangular bitmatrix (in case of 2 not being true).
I don't think we're using a lower triangular bitmap at this point; 
see "mirror_conflicts" in global.c

jeff

Re: Mainline space problem

[James E Wilson]

Daniel Berlin wrote:
> Unless global is doing something completely weird (it may be, i haven't 
> looked at since i worked on new-ra), the conflict matrix is 
> unidirectional (IE if x conflicts with y, then y must conflict with x).
> Thus you can use a lower-triangular bitmatrix, and save half the memory.

If we save half the memory, then we still need over a gigabyte, and we 
still run out of memory.  Constant factors don't help much with 
quadratic problems.  They are still quadratic.

If we try using a sparse bitmaps, then we are adding unnecessary 
overhead for the most common case which will make the compiler run even 
slower than it already does.  If we try to use simple arrays for the 
common case, and sparse bitmaps for the big function case, then we are 
adding complexity, which will make maintenance harder.

I did of course consider the possibility of using some kind of sparse 
matrix representation here, but I didn't think it was worth mentioning. 
  I think we should instead be looking at reducing the number of pseudo 
regs generated for this testcase.

By the way, I did try -fnew-ra.  It used over 980MB and then died with a 
segfault.  I didn't bother looking at why, but I figured if -fnew-ra 
couldn't handle it, then fixing global to handle it was probably not 
feasible.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Mainline space problem

[Joern Rennecke]

> If we try using a sparse bitmaps, then we are adding unnecessary 
> overhead for the most common case which will make the compiler run even 
> slower than it already does.

I'm not so sure about that.  Even for moderately sized problems, the
matrix tends to be sparse, and walking over all the pseudos that conflict
with one particular pseudo is an operation that takes a appreciable
part of the time accessing the data.
If that were not the case, mirroring the conflict matrix and using word
operations wouln't have yielded such a large improvement.

Thus, if we use a sparse matrix representation that has decent single-bit
access times and good row-walking performance, we might even speed up the
compiler for the common case.

Re: Mainline space problem

[Daniel Berlin]

On Aug 31, 2004, at 2:19 PM, James E Wilson wrote:

> Daniel Berlin wrote:
>> Unless global is doing something completely weird (it may be, i 
>> haven't looked at since i worked on new-ra), the conflict matrix is 
>> unidirectional (IE if x conflicts with y, then y must conflict with 
>> x).
>> Thus you can use a lower-triangular bitmatrix, and save half the 
>> memory.
>
> If we save half the memory, then we still need over a gigabyte, and we 
> still run out of memory.  Constant factors don't help much with 
> quadratic problems.  They are still quadratic.

You honestly believe it is not much better to use half as much memory?
That 2 gigabytes and 1 gigabyte aren't that different?

>
> If we try using a sparse bitmaps, then we are adding unnecessary 
> overhead for the most common case which will make the compiler run 
> even slower than it already does.
What makes you think that the common case is the dense case?
It's much more likely to be sparse, otherwise 16 registers wouldn't be 
enough on most platforms when there are more than 16 pseudos in a 
function (and there are often hundreds).

>  If we try to use simple arrays for the common case, and sparse 
> bitmaps for the big function case, then we are adding complexity, 
> which will make maintenance harder.
But it is very useful in other situations as well to use a hybrid 
list/bitmap structure.

>
> I did of course consider the possibility of using some kind of sparse 
> matrix representation here, but I didn't think it was worth 
> mentioning.  I think we should instead be looking at reducing the 
> number of pseudo regs generated for this testcase.
Sure, but that doesn't mean you should avoid improving global simply 
because it might not be enough.
That would tell me you should improve global, *and* do something else.
Then you save even more memory and time.

> By the way, I did try -fnew-ra.  It used over 980MB and then died with 
> a segfault.  I didn't bother looking at why, but I figured if -fnew-ra 
> couldn't handle it, then fixing global to handle it was probably not 
> feasible.
>
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Mainline space problem

[James E Wilson]

On Tue, 2004-08-31 at 11:36, Daniel Berlin wrote:
> You honestly believe it is not much better to use half as much memory?
> That 2 gigabytes and 1 gigabyte aren't that different?

This is an oversimplification, and an insult.  Yes, of course, using
half the memory is better.  But it doesn't fix the underlying bug, as we
still need more memory than what is available for this testcase, and
mainline still uses far more memory than gcc-3.4.

Also, we need to keep in mind that any change to data structures may add
overhead that may make the compiler slower.  The speed of the compiler
is a common complaint.  We should be keeping this in mind.

The underlying problem here, as I have said twice already, is that we
have too many pseudo regs.  Gcc-3.4 needs only about 9K pseudos. 
Mainline needs about 129K pseudos.  That leads to about a 200 times
increase in the memory usage needed, because of the quadratic factor. 
We can reduce that to 100 times by using a lower-triangular bitmatrix as
you mention, but I think this is the wrong approach, as it doesn't fix
the underlying problem, which is too many pseudos.  I believe we should
instead be looking at why we have so many pseudos for this testcase.

We can reduce the memory usage even farther by using sparse matrices,
but that will add even more overhead.  If we replace array references
with function calls, then I think it is likely for the common case that
there will be a performance hit.  This would eliminate the quadratic
factor which would let us compile large function though.  So there is a
trade off here, we can make the compiler slower in the common case in
order to increase the size of functions that we can compile.  It is far
from obvious that this is a good tradeoff.

> What makes you think that the common case is the dense case?

This is a false assumption, and an insult.  I never said the common case
was dense.  What I said, in both previous messages, is that we have too
many pseudo regs.  The common case is a small enough number of pseudos
such that the quadratic memory allocation here isn't a problem.

Obviously the matrix is sparse, particularly in this case.

Apparently you think I'm stupid.  I'm not.  I don't understand why you
feel the need to insult me so.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Mainline space problem

[Robert Dewar]

James E Wilson wrote:

> What I said, in both previous messages, is that we have too
> many pseudo regs.  The common case is a small enough number of pseudos
> such that the quadratic memory allocation here isn't a problem.

I absolutely agree that the problem is too many pseudo-registers.
There is no justification for the large number we see here.

When you have performance of N**2/K

increasing K by a small factor is likely to be much less
significant than reducing N or the 2. Now it is true that using
a sparse matrix representation would indeed reduce the 2, but
I agree with JW that this would likely introduce unacceptable
overhead.

Re: Mainline space problem

[Daniel Berlin]

On Aug 31, 2004, at 3:55 PM, James E Wilson wrote:

> On Tue, 2004-08-31 at 11:36, Daniel Berlin wrote:
>> You honestly believe it is not much better to use half as much memory?
>> That 2 gigabytes and 1 gigabyte aren't that different?
>
> This is an oversimplification, and an insult.
I didn't mean for it to come across as an insult.

>
> Apparently you think I'm stupid.  I'm not.  I don't understand why you
> feel the need to insult me so.
>

Jim, I certainly didn't mean to insult you, and I certainly don't 
believe you are stupid.


> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
>
>

Re: Mainline space problem

[Geert Bosch]

On Aug 31, 2004, at 15:55, James E Wilson wrote:
> The underlying problem here, as I have said twice already, is that we
> have too many pseudo regs.  Gcc-3.4 needs only about 9K pseudos.
> Mainline needs about 129K pseudos.  That leads to about a 200 times
> increase in the memory usage needed, because of the quadratic factor.

A good way of preventing such quadratic behavior, is to divide the
problem into smaller parts and handle them separately. For example,
split a very large function into parts that are processed individually
and insert the necessary code to connect the parts together.

If the problem is very large, chances are the overhead introduced by
the split is small in comparison to the total cost of the function.
Also, forcing such a split shortens live ranges and potentially
allows for more space reuse, further reducing the overhead of
the split.

Currently, the optimizers try to smash an entire function, including
all code that may have been inlined, into a flat piece of code without
scopes. Combined with SSA and tree-level optimizations that work on 
entire
functions and generally may extend live ranges of variables, this may
explain why we need so many pseudos in the first place.

   -Geert

Re: Mainline space problem

[Bradley Lucier]

Thank you for your response.  I'm not a great user of shell scripts, so 
I haven't yet figured out how to use reg_search, but I did cvs_update 
my source tree to June 14 and got the following result:

[descartes:~/programs/gcc/mainline] lucier% objdir/gcc/cc1 -Wall -W 
-Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math 
-fno-strict-aliasing -fomit-frame-pointer -fschedule-insns2 
-fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC 
-fno-common -g  -DHAVE_CONFIG_H _t-c-1.i
  ___H__20___t_2d_c_2d_1
  {GC 18028k -> 8652k} {GC 11710k -> 9765k} {GC 15697k -> 11530k} {GC 
15292k -> 10729k} {GC 15063k -> 10842k} {GC 14845k -> 12163k} {GC 
15911k -> 13031k} ___init_proc
  {GC 17168k -> 8421k} ____20___t_2d_c_2d_1

Execution times (seconds)
  garbage collection    :   0.61 ( 5%) usr   0.02 ( 0%) sys   1.08 ( 4%) 
wall
  cfg construction      :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) 
wall
  cfg cleanup           :   0.13 ( 1%) usr   0.00 ( 0%) sys   0.21 ( 1%) 
wall
  CFG verifier          :   0.62 ( 5%) usr   0.01 ( 0%) sys   0.86 ( 3%) 
wall
  trivially dead code   :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) 
wall
  life analysis         :   0.37 ( 3%) usr   0.13 ( 2%) sys   0.65 ( 3%) 
wall
  life info update      :   0.10 ( 1%) usr   0.00 ( 0%) sys   0.16 ( 1%) 
wall
  alias analysis        :   0.08 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 0%) 
wall
  register scan         :   0.07 ( 1%) usr   0.00 ( 0%) sys   0.07 ( 0%) 
wall
  rebuild jump labels   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) 
wall
  preprocessing         :   0.63 ( 5%) usr   1.20 (21%) sys   2.38 (10%) 
wall
  lexical analysis      :   1.15 ( 9%) usr   2.00 (36%) sys   4.56 (18%) 
wall
  parser                :   0.97 ( 8%) usr   1.26 (23%) sys   3.11 (12%) 
wall
  tree gimplify         :   0.27 ( 2%) usr   0.00 ( 0%) sys   0.38 ( 2%) 
wall
  tree eh               :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) 
wall
  tree CFG construction :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) 
wall
  tree CFG cleanup      :   0.25 ( 2%) usr   0.00 ( 0%) sys   0.31 ( 1%) 
wall
  tree PTA              :   0.19 ( 2%) usr   0.00 ( 0%) sys   0.21 ( 1%) 
wall
  tree alias analysis   :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) 
wall
  tree PHI insertion    :   0.17 ( 1%) usr   0.00 ( 0%) sys   0.27 ( 1%) 
wall
  tree SSA rewrite      :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) 
wall
  tree SSA other        :   0.18 ( 1%) usr   0.19 ( 3%) sys   0.52 ( 2%) 
wall
  tree operand scan     :   0.12 ( 1%) usr   0.22 ( 4%) sys   0.69 ( 3%) 
wall
  dominator optimization:   1.02 ( 8%) usr   0.07 ( 1%) sys   1.37 ( 5%) 
wall
  tree CCP              :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.11 ( 0%) 
wall
  tree split crit edges :   0.08 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 1%) 
wall
  tree PRE              :   0.14 ( 1%) usr   0.10 ( 2%) sys   0.32 ( 1%) 
wall
  tree forward propagate:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) 
wall
  tree conservative DCE :   0.07 ( 1%) usr   0.00 ( 0%) sys   0.13 ( 1%) 
wall
  tree aggressive DCE   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) 
wall
  tree DSE              :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) 
wall
  tree copy headers     :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) 
wall
  tree SSA to normal    :   0.34 ( 3%) usr   0.00 ( 0%) sys   0.50 ( 2%) 
wall
  tree rename SSA copies:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) 
wall
  tree SSA verifier     :   0.86 ( 7%) usr   0.02 ( 0%) sys   1.37 ( 5%) 
wall
  tree STMT verifier    :   0.17 ( 1%) usr   0.02 ( 0%) sys   0.18 ( 1%) 
wall
  dominance frontiers   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) 
wall
  expand                :   0.49 ( 4%) usr   0.05 ( 1%) sys   0.72 ( 3%) 
wall
  varconst              :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.08 ( 0%) 
wall
  jump                  :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) 
wall
  CSE                   :   0.13 ( 1%) usr   0.03 ( 1%) sys   0.25 ( 1%) 
wall
  loop analysis         :   0.15 ( 1%) usr   0.02 ( 0%) sys   0.20 ( 1%) 
wall
  branch prediction     :   0.15 ( 1%) usr   0.01 ( 0%) sys   0.19 ( 1%) 
wall
  flow analysis         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) 
wall
  combiner              :   0.19 ( 2%) usr   0.03 ( 1%) sys   0.30 ( 1%) 
wall
  if-conversion         :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) 
wall
  local alloc           :   0.16 ( 1%) usr   0.02 ( 0%) sys   0.24 ( 1%) 
wall
  global alloc          :   0.79 ( 6%) usr   0.09 ( 2%) sys   1.27 ( 5%) 
wall
  reload CSE regs       :   0.15 ( 1%) usr   0.01 ( 0%) sys   0.21 ( 1%) 
wall
  flow 2                :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) 
wall
  if-conversion 2       :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) 
wall
  rename registers      :   0.18 ( 1%) usr   0.00 ( 0%) sys   0.25 ( 1%) 
wall
  scheduling 2          :   0.25 ( 2%) usr   0.01 ( 0%) sys   0.34 ( 1%) 
wall
  shorten branches      :   0.04 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) 
wall
  final                 :   0.15 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 1%) 
wall
  symout                :   0.00 ( 0%) usr   0.03 ( 1%) sys   0.02 ( 0%) 
wall
  rest of compilation   :   0.10 ( 1%) usr   0.02 ( 0%) sys   0.15 ( 1%) 
wall
  TOTAL                 :  12.22             5.60            25.01
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
[descartes:~/programs/gcc/mainline] lucier% objdir/gcc/xgcc -v
Reading specs from 
/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.5.0/3.5.0/specs
Configured with: ../configure --prefix=/pkgs/gcc-mainline 
--enable-languages=c
Thread model: posix
gcc version 3.5.0 20040614 (experimental)

So it worked then, and doesn't work now.  Perhaps someone could help me 
out with how to use reg_search to find out where things changed.  
(Unfortunately, there were many times in the last 2 1/2 months when the 
mainline didn't bootstrap.)

Brad

Re: Mainline space problem

[Bradley Lucier]

By updating my mainline tree with commands like this:

  cvs update -D "July 22, 2004"

I found that the example program compiled on July 20 and didn't on July 
24.

Bootstrap failed on July 22.

I'll work more on this later.

Brad

Re: Mainline space problem

[Bradley Lucier]

The test file compiled on July 23 and didn't on July 24.

When I say

  cvs update -D "July 23, 2004"

I don't know at what precise time the tree is backed up to.  But after 
that command it worked and after

  cvs update -D "July 24, 2004"

it didn't.

Brad

RE: Mainline space problem

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Bradley Lucier
> Sent: 01 September 2004 19:22

> The test file compiled on July 23 and didn't on July 24.
> 
> When I say
> 
>   cvs update -D "July 23, 2004"
> 
> I don't know at what precise time the tree is backed up to.  
> But after that command it worked and after
> 
>   cvs update -D "July 24, 2004"
> 
> it didn't.
> 
> Brad


  Check the man/info page for cvs.  You can specify a precise time along
with the date, so you can subdivide that 24-hour period if you want to.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Mainline space problem

[Mike Stump]

On Wednesday, September 1, 2004, at 11:22  AM, Bradley Lucier wrote:

> The test file compiled on July 23 and didn't on July 24.
>
> When I say
>
>  cvs update -D "July 23, 2004"
>
> I don't know at what precise time the tree is backed up to.

I always use things like -D "July 23, 2004 1:00", then, I + or - 12, 
then 6, then 3....  coupled with a diff on ChangeLog one can direct the 
search more intelligently based upon the changes there...

Re: Mainline space problem

[Janis Johnson]

On Wed, Sep 01, 2004 at 11:43:28AM -0700, Mike Stump wrote:
> On Wednesday, September 1, 2004, at 11:22  AM, Bradley Lucier wrote:
> 
> >The test file compiled on July 23 and didn't on July 24.
> >
> >When I say
> >
> > cvs update -D "July 23, 2004"
> >
> >I don't know at what precise time the tree is backed up to.
> 
> I always use things like -D "July 23, 2004 1:00", then, I + or - 12, 
> then 6, then 3....  coupled with a diff on ChangeLog one can direct the 
> search more intelligently based upon the changes there...

I always use UTC to avoid confusion about which time zone is being used
where.  The times in 'cvs log' output are UTC.

Janis

Re: Mainline space problem

[Mike Stump]

On Sep 1, 2004, at 4:02 PM, Janis Johnson wrote:
> I always use UTC to avoid confusion about which time zone is being used
> where.  The times in 'cvs log' output are UTC.

Unless you use a new cvs which does it in local time.

Re: Mainline space problem

[James E Wilson]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Tue, 2004-08-31 at 21:17, Bradley Lucier wrote:
> I found that the example program compiled on July 20 and didn't on July 
> 24.

The change that broke it is a cleanup patch from Richard Henderson.
    http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02228.html
The part that specifically caused the problem is the may_be_aliased
change.  Instrumenting this, I see that the old one returns true for
extern variables, but the new one returns false for them.  This is
because there is a !TREE_STATIC check for automatic variables, but
externs also are !TREE_STATIC.  This seems to be a legitimate bug.

With the attached patch, the may_be_aliased function gives the same
result as before for all variables for this testcase.  The testcase can
be compiled again, using about 10K pseudos instead of about 130K
pseudos.

I started a ppc-darwin build to test this.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


[-- Attachment #2: patch.alias.extern --]
[-- Type: text/plain, Size: 1836 bytes --]

2004-09-02  James E Wilson  <wilson@specifixinc.com>

	* tree-ssa-alias.c (may_be_aliased): Move TREE_STATIC check after
	DECL_EXTERNAL check.

Index: tree-ssa-alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.25
diff -p -r2.25 tree-ssa-alias.c
*** tree-ssa-alias.c	25 Aug 2004 21:21:16 -0000	2.25
--- tree-ssa-alias.c	3 Sep 2004 04:44:03 -0000
*************** may_be_aliased (tree var)
*** 2467,2481 ****
    if (TREE_ADDRESSABLE (var))
      return true;
  
-   /* Automatic variables can't have their addresses escape any other way.  */
-   if (!TREE_STATIC (var))
-     return false;
- 
    /* Globally visible variables can have their addresses taken by other
       translation units.  */
    if (DECL_EXTERNAL (var) || TREE_PUBLIC (var))
      return true;
  
    /* If we're in unit-at-a-time mode, then we must have seen all occurrences
       of address-of operators, and so we can trust TREE_ADDRESSABLE.  Otherwise
       we can only be sure the variable isn't addressable if it's local to the
--- 2467,2483 ----
    if (TREE_ADDRESSABLE (var))
      return true;
  
    /* Globally visible variables can have their addresses taken by other
       translation units.  */
    if (DECL_EXTERNAL (var) || TREE_PUBLIC (var))
      return true;
  
+   /* Automatic variables can't have their addresses escape any other way.
+      This must be after the check for global variables, as extern declarations
+      do not have TREE_STATIC set.  */
+   if (!TREE_STATIC (var))
+     return false;
+ 
    /* If we're in unit-at-a-time mode, then we must have seen all occurrences
       of address-of operators, and so we can trust TREE_ADDRESSABLE.  Otherwise
       we can only be sure the variable isn't addressable if it's local to the

Re: Mainline space problem

[Bradley Lucier]

On Sep 3, 2004, at 12:12 AM, James E Wilson wrote:

> With the attached patch, the may_be_aliased function gives the same
> result as before for all variables for this testcase.  The testcase can
> be compiled again, using about 10K pseudos instead of about 130K
> pseudos.

Thank you for the patch.  Unfortunately, mainline doesn't bootstrap  
with or without the patch, with a message of:

/Users/lucier/programs/gcc/mainline/objdir/gcc/xgcc -shared-libgcc  
-B/Users/lucier/programs/gcc/mainline/objdir/gcc/ -nostdinc++  
-L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
libstdc++-v3/src  
-L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
libstdc++-v3/src/.libs  
-B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/  
-B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/lib/ -isystem  
/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/include -isystem  
/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/sys-include  
-DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj  
-I../../../libjava -Iinclude -I../../../libjava/include  
-I../../../libjava/../boehm-gc/include -I../boehm-gc/include  
-I../../../libjava/libltdl -I../../../libjava/libltdl  
-I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib  
-I../../../libjava/../libffi/include -I../libffi/include -O2 -g -O2  
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum  
-D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE  
-DPREFIX=\"/pkgs/gcc-mainline\" -DLIBDIR=\"/pkgs/gcc-mainline/lib\"  
-DBOOT_CLASS_PATH=\"/pkgs/gcc-mainline/share/java/libgcj-3.5.0.jar\"  
-DJAVA_EXT_DIRS=\"/pkgs/gcc-mainline/share/java/ext\" -g -O2 -MT  
interpret.lo -MD -MP -MF .deps/interpret.Tpo -c  
../../../libjava/interpret.cc  -fno-common -DPIC -o .libs/interpret.o
[address=ffffff9d pc=003dd7e8]
../../../libjava/interpret.cc: In member function `void  
_Jv_InterpMethod::run(void*, ffi_raw*)':
../../../libjava/interpret.cc:3220: internal compiler error:  
Segmentation Fault

Re: Mainline space problem

[Diego Novillo]

On Fri, 2004-09-03 at 13:40, Bradley Lucier wrote:
> On Sep 3, 2004, at 12:12 AM, James E Wilson wrote:
> 
> > With the attached patch, the may_be_aliased function gives the same
> > result as before for all variables for this testcase.  The testcase can
> > be compiled again, using about 10K pseudos instead of about 130K
> > pseudos.
> 
> Thank you for the patch.  Unfortunately, mainline doesn't bootstrap  
> with or without the patch, with a message of:
> 
> /Users/lucier/programs/gcc/mainline/objdir/gcc/xgcc -shared-libgcc  
> -B/Users/lucier/programs/gcc/mainline/objdir/gcc/ -nostdinc++  
> -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
> libstdc++-v3/src  
> -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
> libstdc++-v3/src/.libs  
> -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/  
> -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/lib/ -isystem  
> /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/include -isystem  
> /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/sys-include  
> -DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj  
> -I../../../libjava -Iinclude -I../../../libjava/include  
> -I../../../libjava/../boehm-gc/include -I../boehm-gc/include  
> -I../../../libjava/libltdl -I../../../libjava/libltdl  
> -I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib  
> -I../../../libjava/../libffi/include -I../libffi/include -O2 -g -O2  
> -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum  
> -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE  
> -DPREFIX=\"/pkgs/gcc-mainline\" -DLIBDIR=\"/pkgs/gcc-mainline/lib\"  
> -DBOOT_CLASS_PATH=\"/pkgs/gcc-mainline/share/java/libgcj-3.5.0.jar\"  
> -DJAVA_EXT_DIRS=\"/pkgs/gcc-mainline/share/java/ext\" -g -O2 -MT  
> interpret.lo -MD -MP -MF .deps/interpret.Tpo -c  
> ../../../libjava/interpret.cc  -fno-common -DPIC -o .libs/interpret.o
> [address=ffffff9d pc=003dd7e8]
> ../../../libjava/interpret.cc: In member function `void  
> _Jv_InterpMethod::run(void*, ffi_raw*)':
> ../../../libjava/interpret.cc:3220: internal compiler error:  
> Segmentation Fault
> 
Yes.  I ran into this one this morning.  What I observed was that:

(gdb) bt
#0  may_trap_p (x=0xffffff9d)
    at gcc/rtlanal.c:2311
#1  0x102605a4 in try_split (pat=Variable "pat" is not available.)
    at gcc/emit-rtl.c:3329
#2  0x103a93d4 in split_insn (insn=0x4114f3c0)
    at gcc/recog.c:2645
#3  0x103a957c in split_all_insns (upd_life=0)
    at gcc/recog.c:2723
#4  0x10428098 in rest_of_handle_flow2 ()

(gdb) l
3329                  if (CALL_P (insn)
3330                      || (flag_non_call_exceptions
3331                          && may_trap_p (PATTERN (insn))))

(gdb) pr insn
(note 9158 0 0 NOTE_INSN_DELETED)

I'm not quite sure when this was introduced as my ppc box had been off
for a couple of days.


Diego.

Re: Mainline space problem

[Andrew Pinski]

On Sep 3, 2004, at 10:48 AM, Diego Novillo wrote:

> On Fri, 2004-09-03 at 13:40, Bradley Lucier wrote:
>> On Sep 3, 2004, at 12:12 AM, James E Wilson wrote:
>>
>>> With the attached patch, the may_be_aliased function gives the same
>>> result as before for all variables for this testcase.  The testcase 
>>> can
>>> be compiled again, using about 10K pseudos instead of about 130K
>>> pseudos.
>>
>> Thank you for the patch.  Unfortunately, mainline doesn't bootstrap
>> with or without the patch, with a message of:
>>
> Yes.  I ran into this one this morning.  What I observed was that:
>
> (gdb) bt
> #0  may_trap_p (x=0xffffff9d)
>     at gcc/rtlanal.c:2311
> #1  0x102605a4 in try_split (pat=Variable "pat" is not available.)
>     at gcc/emit-rtl.c:3329
> #2  0x103a93d4 in split_insn (insn=0x4114f3c0)
>     at gcc/recog.c:2645
> #3  0x103a957c in split_all_insns (upd_life=0)
>     at gcc/recog.c:2723
> #4  0x10428098 in rest_of_handle_flow2 ()
>
> (gdb) l
> 3329                  if (CALL_P (insn)
> 3330                      || (flag_non_call_exceptions
> 3331                          && may_trap_p (PATTERN (insn))))
>
> (gdb) pr insn
> (note 9158 0 0 NOTE_INSN_DELETED)
>
> I'm not quite sure when this was introduced as my ppc box had been off
> for a couple of days.

I found out that the patch which introduced this failure was (which
means it was latent bug):
+2004-09-02  James E Wilson  <wilson@specifixinc.com>
+
+       * common.opt (ftrapping-math): Default to on.
+

See <http://gcc.gnu.org/ml/gcc-regression/2004-09/msg00006.html>
for the preprocessed source and instructions on how to reproduce it.

Thanks,
Andrew Pinski

Re: Mainline space problem

[James E Wilson]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

Andrew Pinski wrote:
> I found out that the patch which introduced this failure was (which
> means it was latent bug):
> +2004-09-02  James E Wilson  <wilson@specifixinc.com>
> +       * common.opt (ftrapping-math): Default to on.

I checked in the attached patch to fix this.  Mainline bootstraps with 
the patch, but does not bootstrap without it.  I have also started a 
make check, and things look fine so far.

I think the patch that broke it was
     http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01881.html
but the problem went unnoticed until now because flag_trapping_math was 
accidentally turned off earlier.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

[-- Attachment #2: patch.ppc.boot --]
[-- Type: text/plain, Size: 913 bytes --]

2004-09-06  James E Wilson  <wilson@specifixinc.com>

	* emit-rtl.c (try_split): Check INSN_P before may_trap_p call.

Index: emit-rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.410
diff -p -r1.410 emit-rtl.c
*** emit-rtl.c	18 Aug 2004 21:08:20 -0000	1.410
--- emit-rtl.c	6 Sep 2004 20:12:42 -0000
*************** try_split (rtx pat, rtx trial, int last)
*** 3327,3333 ****
  	  while (insn != NULL_RTX)
  	    {
  	      if (CALL_P (insn)
! 		  || (flag_non_call_exceptions
  		      && may_trap_p (PATTERN (insn))))
  		REG_NOTES (insn)
  		  = gen_rtx_EXPR_LIST (REG_EH_REGION,
--- 3327,3333 ----
  	  while (insn != NULL_RTX)
  	    {
  	      if (CALL_P (insn)
! 		  || (flag_non_call_exceptions && INSN_P (insn)
  		      && may_trap_p (PATTERN (insn))))
  		REG_NOTES (insn)
  		  = gen_rtx_EXPR_LIST (REG_EH_REGION,