I have now filled https://gcc.gnu.org/PR92628 as ME bug to track this
(i.e. honor TYPE_RESTRICT for pointer-escape analysis).
Cheers,
Tobias
On 11/21/19 3:36 PM, Tobias Burnus wrote:
On 11/21/19 3:09 PM, Richard Biener wrote:
So I think what you'd need to do is make 'i' marked as TYPE_RESTRIC
Hi Richard,
On 11/21/19 3:09 PM, Richard Biener wrote:
So I think what you'd need to do is make 'i' marked as TYPE_RESTRICT
then. I think we don't yet handle it but it means that bar() may not
modify 'i' but via 'i' (but it doesn't get 'i' as a parameter).
Okay, that would be then the attach
On Thu, Nov 21, 2019 at 2:16 PM Tobias Burnus wrote:
>
> Hi Richard,
>
> On 11/21/19 1:16 PM, Richard Biener wrote:
> > OK, so I found it, it's handled via SSA_NAME_POINTS_TO_READONLY_MEMORY
> > which is initialized during the rewrite into SSA form from the
> > information given by the "fn spec" a
Hi Richard, hi all,
On 11/21/19 2:16 PM, Tobias Burnus wrote:
I wonder whether there is a 'fn attr' which can tell that the first
argument of 'print_i' does not cause the address of 'i' escape.
I think one needs two attributes, one which tells that the address of
the object itself does not es
Hi Richard,
On 11/21/19 1:16 PM, Richard Biener wrote:
OK, so I found it, it's handled via SSA_NAME_POINTS_TO_READONLY_MEMORY
which is initialized during the rewrite into SSA form from the
information given by the "fn spec" attribute […] so when the frontend
sets "fn spec" from the intent it s
On Thu, Nov 21, 2019 at 10:35 AM Tobias Burnus wrote:
>
> On 11/20/19 10:35 PM, Thomas König wrote:
> >> Is there a risk of performance regressions due to higher register
> >> pressure?
>
> richi points out (on IRC) that ideally LTO IPA opts would promote the
> call-by reference to call-by value –
On 11/20/19 10:35 PM, Thomas König wrote:
Is there a risk of performance regressions due to higher register
pressure?
richi points out (on IRC) that ideally LTO IPA opts would promote the
call-by reference to call-by value – but is not sure that it indeed
happens. [In any case, Linux distros
On Thu, Nov 21, 2019 at 12:31 AM Janne Blomqvist
wrote:
>
> On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > > (Why do we zero %eax
> > > before each call? It should not be a variadic call right?)
> >
> > Not sure. Maybe s
Am 20.11.19 um 23:18 schrieb Janne Blomqvist:
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
BTW, since this is done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a) ge
On 11/20/19 11:18 PM, Janne Blomqvist wrote:
Of course, Fortran language rules specify that the call to bar
cannot do anything to n
Hmm, does it? What about the following modification to your testcase:
This code violates (quote from F2018):
"15.5.2.13 Restrictions on entities associated wit
On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
wrote:
>
> On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > (Why do we zero %eax
> > before each call? It should not be a variadic call right?)
>
> Not sure. Maybe some belt and suspenders thing? I guess someone better
> versed in ABI minut
On 11/20/19 10:35 PM, Thomas König wrote:
I haven't run any actual benchmarks.
I think it would be interesting – I think there can be quite some
advantages in some cases, while in most cases, it is not really noticable.
Of course, Fortran language rules specify that the call to bar cannot
do a
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
>
> Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
> > BTW, since this is done for the purpose of optimization, have you done
> > testing on some suitable benchmark suite such as polyhedron, whether
> > it a) generates any different code b) does
Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
BTW, since this is done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a) generates any different code b) does it make it go faster?
I haven't run any actual benchmarks.
Howeve
On Wed, 20 Nov 2019 22:38:30 +0200
Janne Blomqvist wrote:
> On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
> wrote:
> >
> > On 19 November 2019 23:54:55 CET, Thomas Koenig
> > wrote:
> > >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> > >> + char name[GFC_MAX_SYMBO
On Wed, Nov 20, 2019 at 10:38:30PM +0200, Janne Blomqvist wrote:
> On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
> wrote:
> >
> > On 19 November 2019 23:54:55 CET, Thomas Koenig
> > wrote:
> > >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> > >> + char name[GFC_MAX_SYMB
On Sat, Nov 16, 2019 at 10:34 PM Thomas Koenig wrote:
>
> Hello world,
>
> here is an update to the patch.
>
> I have now included variables where the user did not specify INTENT(IN)
> by checking that the dummy variables to be replaced by temporaries
> are not, indeed, assigned a value. This also
On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
wrote:
>
> On 19 November 2019 23:54:55 CET, Thomas Koenig wrote:
> >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> >> + char name[GFC_MAX_SYMBOL_LEN + 1];
> >> + snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_
On 19 November 2019 23:54:55 CET, Thomas Koenig wrote:
>Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
>> + char name[GFC_MAX_SYMBOL_LEN + 1];
>> + snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
>> +f->sym->name);
>> +
>> + if (gfc_get_sym_tr
Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
+ char name[GFC_MAX_SYMBOL_LEN + 1];
+ snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+ f->sym->name);
+
+ if (gfc_get_sym_tree (name, ns, &symtree, false) != 0)
(I) you should + siz
On 16 November 2019 21:33:58 CET, Thomas Koenig wrote:
>Hello world,
>
>here is an update to the patch.
+ char name[GFC_MAX_SYMBOL_LEN + 1];
+ snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+ f->sym->name);
+
+ if (gfc_get_sym_tree (name,
Hello world,
here is an update to the patch.
I have now included variables where the user did not specify INTENT(IN)
by checking that the dummy variables to be replaced by temporaries
are not, indeed, assigned a value. This also includes being passed
as an actual argument to a non-INTENT(IN) dum
Hi Tobias,
I think you need to add at least VOLATILE to this list
Yes, I'll do that.
Any other comments?
Regards
Thomas
Hi Thomas,
On 11/11/19 10:55 PM, Thomas König wrote:
the attached patch loads scalar INTENT(IN) variables to a local
variable at the start of a procedure, as suggested in PR 67202, in
order to aid optimization. This is controlled by front-end
optimization so it is easier to catch if any bugs sh
Hi Tobias,
> On 11/12/19 1:42 PM, Thomas König wrote:
>>> Ah, of course. I should have said module procedures. Or even module
>>> procedures without bind(C)?
>> It would probably be the latter. The change would actually be rather small:
>> If conditions are met, just add attr.value for INTENT(IN
Hi Thomas,
On 11/12/19 1:42 PM, Thomas König wrote:
Ah, of course. I should have said module procedures. Or even module procedures
without bind(C)?
It would probably be the latter. The change would actually be rather small: If
conditions are met, just add attr.value for INTENT(IN). This is so
Hi Janne,
> Ah, of course. I should have said module procedures. Or even module
> procedures without bind(C)?
It would probably be the latter.
The change would actually be rather small: If conditions are met, just add
attr.value for INTENT(IN).
This is something we should probably do when we a
On Tue, Nov 12, 2019 at 12:53 AM Thomas König wrote:
>
> Hi Janne,
>
> > Wouldn't it be even better to pass scalar intent(in) variables by
> > value? The obvious objection of course is ABI, but for procedures with
> > an explicit interface we're not following any particular ABI anyways?
>
> The pr
Hi Janne,
Wouldn't it be even better to pass scalar intent(in) variables by
value? The obvious objection of course is ABI, but for procedures with
an explicit interface we're not following any particular ABI anyways?
The problem with that is that we don't know when we compile a procedure
if it
On Mon, Nov 11, 2019 at 11:56 PM Thomas König wrote:
>
> Hello world,
>
> the attached patch loads scalar INTENT(IN) variables to a local
> variable at the start of a procedure, as suggested in PR 67202, in
> order to aid optimization. This is controlled by front-end
> optimization so it is easie
Am 11.11.19 um 22:55 schrieb Thomas König:
Regression-tested. OK for trunk?
Of course, better with a ChangeLog entry.
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping EXEC_INIT_ASSIG
Hello world,
the attached patch loads scalar INTENT(IN) variables to a local
variable at the start of a procedure, as suggested in PR 67202, in
order to aid optimization. This is controlled by front-end
optimization so it is easier to catch if any bugs should turn up :-)
This is done to make op
32 matches
Mail list logo
