Original Message-
>> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
>> On Behalf Of Jean Christophe Beyler
>> Sent: 15 October 2009 17:27
>> To: Bingfeng Mei
>> Cc: Zdenek Dvorak; gcc@gcc.gnu.org
>> Subject: Re: Turning off unrolling to certain
L
> > levels and suvive all GCC optimization. I still have
> problem in handling
> > combination of unroll and ivdep.
> >
> > Bingfeng
> >
> >> -----Original Message-
> >> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
> >> On Be
4
>> To: Zdenek Dvorak
>> Cc: Bingfeng Mei; gcc@gcc.gnu.org
>> Subject: Re: Turning off unrolling to certain loops
>>
>> You are entirely correct, I hadn't thought that through enough.
>>
>> So I backtracked and have just merged what Bingfeng Mei
> Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: Turning off unrolling to certain loops
>
> You are entirely correct, I hadn't thought that through enough.
>
> So I backtracked and have just merged what Bingfeng Mei has done with
> your code and have now a corrected v
You are entirely correct, I hadn't thought that through enough.
So I backtracked and have just merged what Bingfeng Mei has done with
your code and have now a corrected version of the loop unrolling.
What I did was directly modified tree_unroll_loop to handle the case
of a perfect unroll or not i
Hi,
> I faced a similar issue a while ago. I filed a bug report
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
> I implemented a simple tree-level unrolling pass in our port
> which uses all the existing infrastructure. It works quite well for
> our purpose, but I hesitated t
enek Dvorak
> Cc: gcc@gcc.gnu.org
> Subject: Re: Turning off unrolling to certain loops
>
> Ok, I've actually gone a different route. Instead of waiting for the
> middle end to perform this, I've directly modified the parser stage to
> unroll the loop directly there.
>
Hi,
> Ok, I've actually gone a different route. Instead of waiting for the
> middle end to perform this, I've directly modified the parser stage to
> unroll the loop directly there.
I think this is a very bad idea. First of all, getting the information
needed to decide at this stage whether unro
Ok, I've actually gone a different route. Instead of waiting for the
middle end to perform this, I've directly modified the parser stage to
unroll the loop directly there.
Basically, I take the parser of the for and modify how it adds the
various statements. Telling it to, instead of doing in the
Hi,
> such an epilogue is needed when the # of iterations is not known in the
> compile time; it should be fairly easy to modify the unrolling not to
> emit it when it is not necessary,
Agreed, that is why I was surprised to see this in my simple example.
It seems to me that the whole unrolling p
Hi,
> 2) I was using a simple example:
>
> #pragma unroll 2
> for (i=0;i<6;i++)
> {
> printf ("Hello world\n");
> }
>
> If I do this, instead of transforming the code into :
> for (i=0;i<3;i++)
> {
> printf ("Hello world\n");
>
Dear all,
I've been working on a loop unrolling scheme and I have a few questions:
1) Is there an interest in having a loop unrolling scheme for GCC? I'm
working on the 4.3.2 version but can port it afterwards to the 4.5
version or any version you think is appropriate.
2) I was using a simple ex
Yes, I'd be happy to look into how you did it or where you were up to.
I don't know what I'll be able to do but it might lead me in the right
direction and allow me to finish what you started.
Thanks,
Jc
On Tue, Oct 6, 2009 at 2:53 AM, Zdenek Dvorak wrote:
> Hi,
>
>> I was wondering if it was p
Hi,
> I was wondering if it was possible to turn off the unrolling to
> certain loops. Basically, I'd like the compiler not to consider
> certain loops for unrolling but fail to see how exactly I can achieve
> that.
>
> I've traced the unrolling code to multiple places in the code (I'm
> working
14 matches
Mail list logo
