Dear Bingfeng,
Some time ago I had to deal with a similar issue as
you. Basically I did as follows: I built a backend
function which catches the unroll pragma and replaces
it with a target assembly intrinsic (which of course
has to be described in an .md file). After that in the
RTL unroll phase, I analyze loop by loop and connect
them to the corresponding unrolling intrinsic (which
as a field contains the unrolling factor, you may add
here extra information which allows you to recognize
the loop) from where I decide the unrolling factor.
After that in the RTL unroll phase I remove all the
unroll intrinsics.
hope this will help,
Alex
--- gcc-help@xxxxxxxxxxx wrote:
>
> gcc Digest of: get.146919
>
> Topics (messages 146919 through 146919):
>
> Implement #pragma unroll?
> 146919 by: "Bingfeng Mei" <bmei@xxxxxxxxxxxx>
>
> Administrivia:
>
>
> --- Administrative commands for the gcc list ---
>
> I can handle administrative requests automatically.
> Please
> do not send them to the list address! Instead, send
> your message to the correct command address:
>
> To subscribe to the list, send a message to:
> <gcc-subscribe@xxxxxxxxxxx>
>
> To remove your address from the list, send a message
> to:
> <gcc-unsubscribe@xxxxxxxxxxx>
>
> Send mail to the following for info and FAQ for this
> list:
> <gcc-info@xxxxxxxxxxx>
> <gcc-faq@xxxxxxxxxxx>
>
> Similar addresses exist for the digest list:
> <gcc-digest-subscribe@xxxxxxxxxxx>
> <gcc-digest-unsubscribe@xxxxxxxxxxx>
>
> To get messages 123 through 145 (a maximum of 100
> per request), mail:
> <gcc-get.123_145@xxxxxxxxxxx>
>
> To get an index with subject and author for messages
> 123-456 , mail:
> <gcc-index.123_456@xxxxxxxxxxx>
>
> They are always returned as sets of 100, max 2000
> per request,
> so you'll actually get 100-499.
>
> To receive all messages with the same subject as
> message 12345,
> send an empty message to:
> <gcc-thread.12345@xxxxxxxxxxx>
>
> The messages do not really need to be empty, but I
> will ignore
> their content. Only the ADDRESS you send to is
> important.
>
> You can start a subscription for an alternate
> address,
> for example "john@xxxxxxxxxxx", just add a hyphen
> and your
> address (with '=' instead of '@') after the command
> word:
> <gcc-subscribe-john=host.domain@xxxxxxxxxxx>
>
> To stop subscription for this address, mail:
> <gcc-unsubscribe-john=host.domain@xxxxxxxxxxx>
>
> In both cases, I'll send a confirmation message to
> that address. When
> you receive it, simply reply to it to complete your
> subscription.
>
> If despite following these instructions, you do not
> get the
> desired results, please contact my owner at
> gcc-owner@xxxxxxxxxxxx Please be patient, my owner
> is a
> lot slower than I am ;-)
>
> --- Enclosed is a copy of the request I received.
>
> Return-Path: <aturjan@xxxxxxxxx>
> Received: (qmail 24604 invoked by uid 22791); 29 May
> 2008 13:01:01 -0000
> X-Spam-Status: No, hits=1.9 required=5.0
>
>
tests=AWL,BAYES_00,EMPTY_MESSAGE,MISSING_SUBJECT,TVD_SPACE_RATIO
> X-Spam-Check-By: sourceware.org
> Received: from web62409.mail.re1.yahoo.com (HELO
> web62409.mail.re1.yahoo.com) (69.147.75.86)
> by sourceware.org (qpsmtpd/0.31) with SMTP; Thu,
> 29 May 2008 13:00:41 +0000
> Received: (qmail 58099 invoked by uid 60001); 29 May
> 2008 13:00:39 -0000
> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
> s=s1024; d=yahoo.com;
>
>
h=X-YMail-OSG:Received:Date:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
>
>
b=KVX550rEsn1vVYXDZGzSg1iYz+9xhBBaPkpUN/a2NiLEkeCB5ZRj8sOjcksDUhuI2Z7xcsqBTjHCQAwlZLorsXuhzq+sqXfFV5YFQ7hsyzODW1q1G5/n3fQL7pmbzGB/PaH04ivSuUaq8g4S6IqZ/Mkm6AL3HsTzi/s7y1T5YlI=;
> X-YMail-OSG:
>
is7GqMoVM1m0leSRg_9soYaQ6do.CshBuVdAo9E7MeqsxhDshCX6gWYTIKHVvtIl_NV799R7CLk-
> Received: from [80.255.245.177] by
> web62409.mail.re1.yahoo.com via HTTP; Thu, 29 May
> 2008 06:00:39 PDT
> Date: Thu, 29 May 2008 06:00:39 -0700 (PDT)
> From: Alex Turjan <aturjan@xxxxxxxxx>
> To: gcc-get.146919@xxxxxxxxxxx
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> Message-ID:
> <565468.57703.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
>
>
>
>
>
>
>
----------------------------------------------------------------------
> > Subject: Implement #pragma unroll?
> Date: Thu, 29 May 2008 02:51:49 -0700
> From: "Bingfeng Mei" <bmei@xxxxxxxxxxxx>
> To: gcc@xxxxxxxxxxx
>
> Hello,
> In porting GCC to our VLIW, we would like to
> implement #pragma unroll to
> manually specify unrolling factor, hoping to achieve
> better performance
> in some cases without changing code itself. As far
> as I know, #pragma
> unroll is present in both HPUX aCC and INTEL icc. I
> examined pragma
> implementations of some other GCC targets (arm,
> m32c, etc). It seems
> that these pragmas are interchangeable with
> __attribute__, meaning they
> are attached to either a type or a declaration. But
> for loop, it is
> neither a type or a declaration. In fact, when I
> tracked into GCC,
> LOOP_EXPR related stuff is never used. Do/while/for
> loops are lowered to
> individual statements in parsing stage. At best, I
> can find a compound
> statement (statement_list) that represent a loop.
> Maybe I can invent
> some attribute for unrolling factor and attach it to
> the compound
> statement. But I am not sure whether later
> optimization (before loop
> unrolling) will remove or change it. I also need to
> change many places
> in the gcc code itself, which is not nice. Is there
> any better way to do
> this? Thanks in advance.
>
> BTW, I am working on GCC 4.3.0. Is there any future
> plan for GCC to
> implement #pragma unroll or provide infrastructure
> to implement similar
> #pragma? I can see it will be quite useful for many
> targets.
>
> Cheers,
> Bingfeng Mei
> Broadcom UK
>
>
