This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CSE memory leaks and old problems
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: CSE memory leaks and old problems
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Wed, 11 Jul 2001 17:13:56 -0400
- Cc: dan at cgsoftware dot com, gcc at gcc dot gnu dot org
- References: <10107112056.AA20218@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> I removed this flush, and can't see the quadratic behavior it's
> referring to.
>
> I put that in. The issue is that the number of things that cause
> invalidation of memory (e.g., calls) are a linear function of the size of a
> basic block and the number of things each needs to examine in the table
> is also a linear function of the size of the block and so the aggregate
> affect is quadratic in the size of the block.
I don't buy the first part.
The number of things invalidating memory has nothing to do with the
size of the block.
It has to do with whatever your program does.
If you put tons of calls or mem stores, you'll have tons of calls and
memstores needing invalidating, if you have none, you'll not have tons
of calls and memstores needing invalidating.
>
> I tried functions with 15k insns in them,
>
> Try functions with something like 30k insn in a single basic block and
> you'll get the behavior I put that in to prevent. We were talking about
> compile times measures in tens of minutes.
I just did.
Still no difference.
CSE sits at 7% of compilation time.
--
"I went to the hardware store and bought some used paint. It was
in the shape of a house. I also bought some batteries, but they
weren't included. So I had to buy them again.
"-Steven Wright