Right commit revision, wrong attached file (original patch, not the
follow-up one).
Now hopefully the correct one.
Tobias
Am 15.10.18 um 21:02 schrieb Tobias Burnus:
Fixed with commit Rev. 265175 as attached.
Cheers
Tobias
Dominique d'Humières wrote:
Le 14 oct. 2018 à 00:43, Tobias Burnu
Fixed with commit Rev. 265175 as attached.
Cheers
Tobias
Dominique d'Humières wrote:
Le 14 oct. 2018 à 00:43, Tobias Burnus a écrit :
Dominique d'Humières wrote:
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times optimized
"gamma5[__var_1_do * 4 + __var_2_
> Le 14 oct. 2018 à 00:43, Tobias Burnus a écrit :
>
> Hi Dominique,
>
> Dominique d'Humières wrote:
>> UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
>> optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
>>
>> ! { dg-final { scan-tree-dump-times "gamma5\[_
Hi Dominique,
Dominique d'Humières wrote:
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times optimized
"gamma5[__var_1_do * 4 + __var_2_do]" 1
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]" 1
"optimized" } }
Shouldn’t -fdump-tre
Hi Tobias,
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O1 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.
Hi Tobias,
Build and regtested on x86-64-linux.
OK for the trunk and - after a grace time - for GCC 6, 7 and 8?
Thanks for taking this on so quickly! I don't think that this will
result in any missed optimizations.
Ok.
Thomas
In the front-end optimization for matmul, we call lbound() for each matrix
argument to obtain the shift to the 0-based loop variables.
If the first argument is a PARAMETER, it appears initially as EXPR_VARIABLE
and has associated ref->u.ar for the AR_FULL and ref->u.ar.as contains the
bounds.
Run
