https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
Richard Biener changed:
What|Removed |Added
Known to work||14.2.0
Status|NEW
--- Comment #18 from jacob at math dot jussieu dot fr 2006-12-14 16:47
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
I shouldn't elaborate on this as this is not the subject of this bug report,
bu
--- Comment #17 from jacob at math dot jussieu dot fr 2006-12-14 16:34
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
ah right, I initially misread "unroll" as "unnest", but it is true that I can
u
--- Comment #16 from jacob at math dot jussieu dot fr 2006-12-14 16:28
---
(In reply to comment #15)
> If the loop bounds are compile-time constants you can use template
> metaprogramming to unroll them.
>
That is true, I will think about that.
I was also mentionning my loop-unnestin
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-14 16:24
---
If the loop bounds are compile-time constants you can use template
metaprogramming to unroll them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
--- Comment #14 from jacob at math dot jussieu dot fr 2006-12-14 16:24
---
I forgot to say that size() is an inline function returning a constant that is
known at compile-time (a template parameter). Otherwise, of course, I wouldn't
expect these loops to get unrolled...
--
http://g
--- Comment #13 from jacob at math dot jussieu dot fr 2006-12-14 16:22
---
(In reply to comment #12)
> Yes. However, all this is only for my reduced testcase without the use of
> the C++ class. For the original testcase, the issues Andrew P. identified
> are still true.
OK, so if I und
--- Comment #12 from bangerth at math dot tamu dot edu 2006-12-14 16:08
---
Subject: Re: gcc doesn't unroll nested loops
> Very interesting, thanks... so does it mean that gcc did loop unrolling after
> all? (sorry, I'm a newbie when it comes to compiler/assembler stuff).
Yes.
> A
--- Comment #11 from jacob at math dot jussieu dot fr 2006-12-14 15:56
---
Very interesting, thanks... so does it mean that gcc did loop unrolling after
all? (sorry, I'm a newbie when it comes to compiler/assembler stuff).
And the speed difference was only caused by the compiler unders
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-12-14 15:46
---
I get on the trunk with -O2 -funroll-loops
main:
.LFB2:
xorl%eax, %eax
.p2align 4,,7
.L2:
cvtsi2sd%eax, %xmm0
addl$1, %eax
cmpl$10, %eax
--- Comment #9 from bangerth at dealii dot org 2006-12-14 15:41 ---
Hm, now, with -DUNROLL, gcc realizes that it writes to data[] all the
times with no reads and moves all the writes out of the loop. I suppose
it's no surprise that the code is fast (the loop looks pretty atrocious,
thoug
--- Comment #8 from bangerth at dealii dot org 2006-12-14 15:35 ---
Here is an analysis of the assembler code we get when using
my first command line in my previous comment, i.e. no hand unrolling.
I'm using 4.1.0, btw.
The main loop looks like this:
--
.L2:
--- Comment #7 from bangerth at dealii dot org 2006-12-14 15:16 ---
I've reduced the code a bit by stripping all C++isms and collapsing
everything into a single function:
---
double data[9];
int main()
{
for( int factor = 0; factor < 10; factor+
--- Comment #6 from jacob at math dot jussieu dot fr 2006-12-13 20:24
---
(In reply to comment #4)
> most likely not in 4.2. I think something could be done in 4.3 timeframe.
ah, ok. Thanks for the information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
--- Comment #5 from jacob at math dot jussieu dot fr 2006-12-13 20:22
---
Nope... with -O3 -ffast-math I get 1.9 seconds in average (this is a laptop
with CPU frequency scaling, so it's difficult to get precise numbers). Adding
-funroll-loops in addition to -ffast-math doesn't seem to m
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-12-13 20:22 ---
Subject: Re: gcc doesn't unroll nested loops
> Not understanding much in compiler stuff, I tried what you said, namely
> replace
> the loop with
>
> for( int i = 0; i < 3; i++ )
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-13 18:56 ---
(In reply to comment #2)
> than the original 1.9 seconds, but still far from the 0.3 seconds I get
> manually unrolling the loop.
Try with -ffast-math, you should get the same speed. Again the problem is with
signe
--- Comment #2 from jacob at math dot jussieu dot fr 2006-12-13 18:54
---
Not understanding much in compiler stuff, I tried what you said, namely replace
the loop with
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
{
bool a = (i == j);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 16:33 ---
Actually there are two issues with this bug, one issue is that we change
(float)(CMP) into CMP?1.0:0.0 early on which in the end causes us to produce
three different versions of the inner loop. If we write the inner
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |middle-end
h
20 matches
Mail list logo
