This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC question
- From: Robert Bernecky <bernecky at acm dot org>
- To: gcc at gcc dot gnu dot org, David Edelsohn <edelsohn at us dot ibm dot com>
- Date: Fri, 10 Jun 2005 09:37:02 -0400 (EDT)
- Subject: Re: GCC question
- References: <OFE65E91CB.007DAF79-ON8525701B.0062A53C-8525701B.00635711@us.ibm.com>
- Reply_to: "Robert Bernecky" <bernecky@acm.org>
Thanks for your help, David,
Please accept my apologies for not asking the public forum.
I'll do that now...
GCCers, please fill me in on the roadmap and who is working in
this area.
Thanks and regards,
Robert
On Thu, 9 Jun 2005, David Edelsohn wrote:
> There are plans to implement loop fusion / array contraction in
> GCC based on the Tree-SSA data dependence analysis infrastructure now
> implemented in GCC. You need to ask the GCC community through the
> gcc@gcc.gnu.org mailinglist about the roadmap. A number of members of the
> GCC community are working on the problem, but each has his or her own
> priority and funding resources.
>
> You should ask these questions publicly, not contacting individual
> developers privately.
>
> David
>
> To: David Edelsohn/Watson/IBM@IBMUS
> cc:
> Subject: GCC question
>
>
>
> Hi, Dr. Edelsohn,
>
> I just read your Systems Journal article about GCC,
> and was wondering if you can answer a question
> about it for me:
>
> I see veiled references to loop fusion/array contraction in GCC on
> the web, but it looks like it only works for Fortran code.
> Also, a few simple experiments I've made with it seem to
> indicate that loop fusion is not performed by the compiler.
>
> So...
>
> 1. Are there plans to introduce loop fusion/array contraction
> into GCC?
>
> 2. If so, who would I contact in that regard?
>
> 3. If not, do you have any idea of the approximate difficulty
> of doing that in the post-SSA version of the compiler?
> If it's not onerous, I may be able to take on the job, as
> I otherwise have to introduce similar facilities into
> other compilers, and I'd rather do the job just once...
>
> The reason I'm doing this is that I'm working on array language
> compilers (APL, J, SAC), and these optimizations are key to
> getting acceptable run-time performance in those tongues.
>
> Thanks,
> Robert
>
>
>
>