Zdenek's patch here -
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02291.html - solved the
problem.
Kenny, Zdenek - many thanks for solving this issue!
dorit
> "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> wrote on
> 29/08/2007 01:01:42:
>
> > On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 30 Aug 2007, Kenneth Zadeck wrote:
> Michael and Bernd,
>
> I you look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224 you will
> see that this bug has nothing to do with the type of def. It is pilot
> error on the author of the loop unrolling code. They are looking in the
Michael Matz wrote:
> Hi,
>
> On Wed, 29 Aug 2007, Bernd Schmidt wrote:
>
>
>>> Apart from that I agree that in the case of conditional defs multiple
>>> ones might reach a use. I disagree for partial defs, if one dominates
>>> the other. For most cases (except register allocation) a partial
Hi,
On Wed, 29 Aug 2007, Bernd Schmidt wrote:
> > Apart from that I agree that in the case of conditional defs multiple
> > ones might reach a use. I disagree for partial defs, if one dominates
> > the other. For most cases (except register allocation) a partial def
> > is just a complete kil
Michael Matz wrote:
Apart from that I agree that in the case of conditional defs multiple ones
might reach a use. I disagree for partial defs, if one dominates the
other. For most cases (except register allocation) a partial def is just
a complete killing def, which happens to leave some co
"Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> wrote on
29/08/2007 01:01:42:
> On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> ...
> > that obviously is not the case here, though. Do you (or someone else
> > responsible for df) have time to have a look at this problem?
> > Otherwise, we ma
On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
...
> that obviously is not the case here, though. Do you (or someone else
> responsible for df) have time to have a look at this problem?
> Otherwise, we may discuss it forever, but we will not get anywhere.
>
> Zdenek
Open a PR and assign it
Hello,
> And finally at the stage of rtl unrolling it looks like this:
> [6] r186 = r2 + C;
> r318 = r186 + 160;
> loop:
> r186 = r186 + 16
> if (r186 != r318) then goto loop else exit
>
> Then, in loop-unroll.c we call iv_number_of
On Tue, 28 Aug 2007, Kenneth Zadeck wrote:
> And finally at the stage of rtl unrolling it looks like this:
> [6] r186 = r2 + C;
> r318 = r186 + 160;
> loop:
> r186 = r186 + 16
> if (r186 != r318) then goto loop else exit
>
> >
> > regard
Zdenek Dvorak wrote:
> Hello,
>
>
And finally at the stage of rtl unrolling it looks like this:
[6] r186 = r2 + C;
r318 = r186 + 160;
loop:
r186 = r186 + 16
if (r186 != r318) then goto loop else exit
Then, in loop-unroll.c we call
Hello,
> >> And finally at the stage of rtl unrolling it looks like this:
> >> [6] r186 = r2 + C;
> >> r318 = r186 + 160;
> >> loop:
> >> r186 = r186 + 16
> >> if (r186 != r318) then goto loop else exit
> >>
> >> Then, in loop-unroll.c we call iv_number_of_iterations, whi
Zdenek Dvorak wrote:
> Hello,
>
>
>> And finally at the stage of rtl unrolling it looks like this:
>> [6] r186 = r2 + C;
>> r318 = r186 + 160;
>> loop:
>> r186 = r186 + 16
>> if (r186 != r318) then goto loop else exit
>>
>> Then, in loop-unroll.c we call iv_number_of_it
Hello,
> And finally at the stage of rtl unrolling it looks like this:
> [6] r186 = r2 + C;
> r318 = r186 + 160;
> loop:
> r186 = r186 + 16
> if (r186 != r318) then goto loop else exit
>
> Then, in loop-unroll.c we call iv_number_of_iterations, which eventually
> calls i
Hi,
I have a question about a loop that when vectorized does not get unrolled
(by the rtl-level unroller), whereas the same loop when not vectorized does
get unrolled. This is the testcase:
#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
int i,j,k;
float diff;
for (
14 matches
Mail list logo
