https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #50 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #49)
> The second loop:
>
> .L3:
> leaq8(%rsp), %rdi
> callintent_in_
> movl%ebx, 8(%rsp)
> addl$1, %ebx
> cmpl$12,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #49 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #48)
> Forgive me, I wasn't aware of this oversight which may have turned away
> people who could fix this for the past 6 years.
That didn't happen :-)
Unfortunate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
Tobias Schlüter changed:
What|Removed |Added
Assignee|tobi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #47 from Dominique d'Humieres ---
The assignee is Tobias Schlüter, but the PR is not marked as assigned.
Is Tobias still interested? If no, the PR should be unassigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
Tobias Schlüter changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #46 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #45)
> Anything left to fix in this PR?
Unfortunately yes...
We still do not take advantage of the fact that the call
to a subroutine cannot change the value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #45 from Dominique d'Humieres ---
Anything left to fix in this PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
Bug 31593 depends on bug 31094, which changed state.
Bug 31094 Summary: Support annotating function parameters as read-only and/or
non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
What|Removed |Ad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #44 from Thomas Koenig 2010-10-16
16:06:16 UTC ---
Author: tkoenig
Date: Sat Oct 16 16:06:07 2010
New Revision: 165559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165559
Log:
2010-10-16 Thomas Koenig
PR fortran/2016
--- Comment #43 from matz at gcc dot gnu dot org 2009-10-08 11:24 ---
There already is PR31094 about this enhancement.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #42 from steven at gcc dot gnu dot org 2009-10-08 11:06 ---
Add Matz, following comment #40. Micha, maybe you can open a separate bug
report for the issues you mention in your mail
(http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html) and make that new PR
block this existing
--- Comment #41 from tobi at gcc dot gnu dot org 2009-08-17 22:39 ---
(In reply to comment #40)
One more thing: my previous benchmarks were wrong, I had an error in my setup.
With a correct benchmark, polyhedron improves slightly in the testcases where
the change is outside the measure
--- Comment #40 from tobi at gcc dot gnu dot org 2009-08-17 22:08 ---
Created an attachment (id=18392)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18392&action=view)
Patch for savin function arguments
This patch copies do loops which are passed as actual arguments to a temporary
--- Comment #39 from tobi at gcc dot gnu dot org 2009-08-16 17:00 ---
Sigh, with the patch capacita.f90 loses 4%. Your testcase really is nasty,
Thomas! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #38 from tobi at gcc dot gnu dot org 2009-08-16 16:20 ---
Thanks(In reply to comment #37)
> Subject: Re: Invariant DO loop variables and subroutines
>
> On Sun, 2009-08-16 at 15:57 +, tobi at gcc dot gnu dot org wrote:
> > Now I only need to figure out how to make that
--- Comment #37 from tkoenig at gcc dot gnu dot org 2009-08-16 16:12
---
Subject: Re: Invariant DO loop variables and subroutines
On Sun, 2009-08-16 at 15:57 +, tobi at gcc dot gnu dot org wrote:
> Now I only need to figure out how to make that patch pass the
> testsuite :)
If yo
--- Comment #36 from tobi at gcc dot gnu dot org 2009-08-16 15:57 ---
I have a patch which copies DO loop variables that are passed as arguments to
functions, which gives the same speedup as enclosing the arguments into
parentheses. Now I only need to figure out how to make that patch p
--- Comment #35 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
2009-08-15 10:58
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
> --- Comment #34 from tkoenig at gcc dot gnu dot org 2009-08-15 10:57
> ---
> (In reply to comment #
--- Comment #34 from tkoenig at gcc dot gnu dot org 2009-08-15 10:57
---
(In reply to comment #33)
> Actually, we're buggy there, and my patch fixes it. I'm just now trying
> out testcases.
Are we really buggy?
$ cat gaga.f90
n=10
do i=1,n
call foo(n)
print *,i
end do
end
subrouti
--- Comment #33 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
2009-08-15 10:17
---
Subject: Re: Invariant DO loop variables and subroutines
jv244 at cam dot ac dot uk wrote:
> --- Comment #32 from jv244 at cam dot ac dot uk 2009-08-15 10:05 ---
> (In reply to comment #29)
>
>> I
--- Comment #32 from jv244 at cam dot ac dot uk 2009-08-15 10:05 ---
(In reply to comment #29)
> It's the other way around: If output were to modify any of its
> arguments, the program would be illegal. Therefore, the compiler can
> assume that this doesn't happen. Intent(in) would b
--- Comment #31 from tobi at gcc dot gnu dot org 2009-08-15 09:51 ---
(In reply to comment #30)
> Escaping pointers for non-target dummy arguments can't happen in
> Fortran, can they? Could we just disable this (or ad a
> TREE_CANNOT_ALIAS flag to the middle end, which is on by default
--- Comment #30 from tkoenig at gcc dot gnu dot org 2009-08-15 09:25
---
Subject: Re: Invariant DO loop variables and subroutines
On Fri, 2009-08-14 at 22:58 +, tobi at gcc dot gnu dot org wrote:
>
> --- Comment #26 from tobi at gcc dot gnu dot org 2009-08-14 22:58 ---
>
--- Comment #29 from tkoenig at gcc dot gnu dot org 2009-08-15 09:22
---
Subject: Re: Invariant DO loop variables and subroutines
On Sat, 2009-08-15 at 07:53 +, jv244 at cam dot ac dot uk wrote:
>
> --- Comment #28 from jv244 at cam dot ac dot uk 2009-08-15 07:53 ---
> (
--- Comment #28 from jv244 at cam dot ac dot uk 2009-08-15 07:53 ---
(In reply to comment #23)
> subroutine output(i1,i2,i3,i4,i5)
> print '(5(I0,:" "))',i1,i2,i3,i4,i5
> end subroutine output
[..]
> if (p1 * p2 * p3 * p4 == value * 100) &
--- Comment #27 from jv244 at cam dot ac dot uk 2009-08-15 07:50 ---
(In reply to comment #26)
> If it weren't for the outermost loop it would actually be perfectly legal to
> modify 'value' inside the loops. If there were a way of telling the compiler
> "this pointer can't escape" this
--- Comment #26 from tobi at gcc dot gnu dot org 2009-08-14 22:58 ---
(In reply to comment #25)
> (In reply to comment #23)
>
> Actually, you're right. In nested loops, there's no way without copying.
>
If it weren't for the outermost loop it would actually be perfectly legal to
modif
--- Comment #25 from tobi at gcc dot gnu dot org 2009-08-14 22:46 ---
(In reply to comment #23)
Actually, you're right. In nested loops, there's no way without copying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #24 from tobi at gcc dot gnu dot org 2009-08-14 22:38 ---
(In reply to comment #23)
That's sad. I'm guessing that everytime it enters one of the inner loops, it
has to deal with the fact that the upper bound escaped. A way without all the
copying would be to set the DO var
--- Comment #23 from tkoenig at gcc dot gnu dot org 2009-08-14 22:05
---
(In reply to comment #20)
> Created an attachment (id=18369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18369&action=view) [edit]
> updated patch
>
> Corrected patch, I copied the variables in the wrong o
--- Comment #22 from tobi at gcc dot gnu dot org 2009-08-14 21:46 ---
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > From quickly looking at the code, the copy to real_to is probably
> > unnecessary
> > because loop bounds are passed through gfc_
--- Comment #21 from tobi at gcc dot gnu dot org 2009-08-14 21:44 ---
(In reply to comment #19)
> (In reply to comment #17)
> From quickly looking at the code, the copy to real_to is probably unnecessary
> because loop bounds are passed through gfc_evaluate_now before calling
> gfc_trans
--- Comment #20 from tobi at gcc dot gnu dot org 2009-08-14 21:31 ---
Created an attachment (id=18369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18369&action=view)
updated patch
Corrected patch, I copied the variables in the wrong order on loop entry,
clobbering the upper boun
--- Comment #19 from mikael at gcc dot gnu dot org 2009-08-14 21:18 ---
(In reply to comment #17)
>From quickly looking at the code, the copy to real_to is probably unnecessary
because loop bounds are passed through gfc_evaluate_now before calling
gfc_trans_simple_do ( never mind if it g
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-08-14 20:18
---
Patch applied cleanly, building , and will test shortly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #17 from tobi at gcc dot gnu dot org 2009-08-14 19:55 ---
Created an attachment (id=18368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18368&action=view)
Speed up loops where the loop variable is used as function argument inside the
loop
This patch gives the good ass
--- Comment #16 from tobi at gcc dot gnu dot org 2009-08-14 19:28 ---
Created an attachment (id=18367)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18367&action=view)
use const * when writing
Thomas, can you please test the attached patch with your testcase from comment
#6. I ca
--- Comment #15 from tobi at gcc dot gnu dot org 2009-08-14 18:12 ---
I'm wondering if instead we can't simply mark all arguments to the transfer
functions in PRINT, WRITE and INTENT(IN) arguments as 'const *' instead of '*'.
Are there any reasons against this? I can't think of any exc
--- Comment #14 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
2009-08-13 23:33
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
> --- Comment #13 from tkoenig at gcc dot gnu dot org 2009-08-13 18:55
> ---
> (In reply to comment #
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-08-13 18:55
---
(In reply to comment #12)
> That's exactly what Thomas is achieving by adding parentheses. Thomas, If you
> want to tackle something more difficult, I'm willing to do this over the
> weekend in order to warm up m
--- Comment #12 from tobi at gcc dot gnu dot org 2009-08-13 13:39 ---
(In reply to comment #11)
> DO i = 1,10
> call bar(i)
> END DO
>
> if bar may not modify i then the frontend can simply communicate that to the
> middle-end by doing
>
> DO i = 1,10
> j = i;
> call
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-13 13:30
---
DO i = 1,10
call bar(i)
END DO
if bar may not modify i then the frontend can simply communicate that to the
middle-end by doing
DO i = 1,10
j = i;
call bar (j)
END DO
likewise if loop bounds
--- Comment #10 from jv244 at cam dot ac dot uk 2009-08-13 09:13 ---
(In reply to comment #9)
I believe there are at least two important independent issues. One is the fact
that the compiler ignores INTENT(IN) and similarly issues (see also PR 40194).
This holds for general variables. L
--- Comment #9 from tobi at gcc dot gnu dot org 2009-08-12 20:52 ---
Side remark:
DO i = 1,10
call bar(i)
END DO
wouldn't be valid if bar changed its argument, i.e. the compiler should
generate the same, better code it does for the case where you copy the argument
(bar((i))).
I
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-08-12 20:36 ---
(In reply to comment #7)
> An interesting approach. As long as you don't print array slices in the
> loops this should work around the escaping pointer problem. It comes at
> the risk of creating excessive copie
--- Comment #7 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
2009-08-12 18:11
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
> --- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-12 17:53
> ---
> We get a dramatic speedu
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-12 17:53 ---
We get a dramatic speedup when enclosing the arguments to
print in parentheses:
This is something we can do for
- write and print statements
- intent(in) arguments
- any do variable passed as an argument within the
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-02 12:36 ---
> > call output (p1, p2, p3, p4)
> > That still clobbers p1, p2, p3, and p4 as they are passed by reference so
> > is it really undefined code if output changes the values for the do loop?
> Yes.
Conf
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-17 01:14 ---
(In reply to comment #3)
> call output (p1, p2, p3, p4)
>
> That still clobbers p1, p2, p3, and p4 as they are passed by reference so is
> it
> really undefined code if output changes the values for th
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-16 23:12 ---
call output (p1, p2, p3, p4)
That still clobbers p1, p2, p3, and p4 as they are passed by reference so is it
really undefined code if output changes the values for the do loop?
--
http://gcc.gnu
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-04-16 23:03 ---
(In reply to comment #1)
> This is not suprising as it is a dup of bug 20165 anyways.
>
> *** This bug has been marked as a duplicate of 20165 ***
Only one part.
The other part is that we don't mark the variables
53 matches
Mail list logo
