This is the mail archive of the
mailing list for the GCC project.
Re: Question on param MAX_PENDING_LIST_LENGTH in sched-deps
- From: Jeff Law <law at redhat dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 06 Nov 2014 16:10:43 -0700
- Subject: Re: Question on param MAX_PENDING_LIST_LENGTH in sched-deps
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci2-r0DRCbU+dwEU-BgJgBVth7oFKEYHFA5ran+8gdk0ZdQ at mail dot gmail dot com>
On 11/04/14 20:29, Bin.Cheng wrote:
Yea, seems like a bit of a nit. Might be worth fixing as someone might
size an array based on the param's value only to find out it can have an
The parameter MAX_PENDING_LIST_LENGTH is set to 32 by default. It
seems to me the length of pending list can't be larger than 32. But
in sched-deps.c, below code is used:
/* Pending lists can't get larger with a readonly context. */
&& ((deps->pending_read_list_length + deps->pending_write_list_length)
Since we compares it using ">", the list can have 33 instructions at
most, which is inconsistent with the parameter name.
Well, it's some kind of nit picking.
Another question. This parameter is introduced to prevent GCC from
running for too long time. I am not clear if the running time is a
quadratic function of pending list, or a quadratic function of
dependency nodes? If it's the latter, could we use the number of
dependency nodes as the parameter directly? Because in some cases
like memory initialization, there are more than 32 store instructions
in flow, but the dependency are actually very simple.
I don't recall what part of the algorithm was quadratic, but it should
be too hard to find out given the thread references the target & the