This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran, RFC] First steps towards inlining matmul
- From: Dominique d'Humières <dominiq at lps dot ens dot fr>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, GNU GFortran <fortran at gcc dot gnu dot org>, jvdelisle at charter dot net
- Date: Mon, 6 Apr 2015 14:18:34 +0200
- Subject: Re: [patch, fortran, RFC] First steps towards inlining matmul
- Authentication-results: sourceware.org; auth=none
- References: <20150405135519 dot AF21A105 at mailhost dot lps dot ens dot fr> <552147A3 dot 7000603 at netcologne dot de> <4DA1047C-92D3-485A-9457-61655ED14681 at lps dot ens dot fr> <55219D1C dot 6070507 at netcologne dot de> <9F588746-B32C-4919-AEFC-4EF5E6792001 at lps dot ens dot fr>
> Le 6 avr. 2015 à 01:15, Dominique d'Humières <dominiq@lps.ens.fr> a écrit :
>
> The patch causes the following regressions:
>
> FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (internal compiler error)
> …
> FAIL: gfortran.dg/bound_8.f90 -g -flto (test for excess errors)
>
> I think the line
>
> if (!upper && as->type == AS_ASSUMED_SHAPE && dim)
>
> should be something such as (untested)
>
> if (!upper && dim && as && as->type == AS_ASSUMED_SHAPE)
This fixes a first batch of ICEs. A second one if fixed by
if (kind && lower->expr_type == EXPR_CONSTANT)
While the first change is obvious, I am not sure about the second one.
With this changes I am left with the following regressions
FAIL: gfortran.dg/function_optimize_1.f90 -O scan-tree-dump-times original "matmul_r4" 1
FAIL: gfortran.dg/function_optimize_7.f90 -O scan-tree-dump-times original "matmul_r4" 1
FAIL: gfortran.dg/function_optimize_2.f90 -O scan-tree-dump-times original "matmul_r4" 1
FAIL: gfortran.dg/matmul_bounds_2.f90 -O1 output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -O2 output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -O3 -fomit-frame-pointer output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -O3 -fomit-frame-pointer -funroll-loops output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -O3 -g output pattern test
FAIL: gfortran.dg/matmul_bounds_2.f90 -Os output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O1 output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O2 output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O3 -fomit-frame-pointer output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O3 -fomit-frame-pointer -funroll-loops output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -O3 -g output pattern test
FAIL: gfortran.dg/matmul_bounds_3.f90 -Os output pattern test
FAIL: gfortran.dg/realloc_on_assign_11.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/realloc_on_assign_11.f90 -O3 -fomit-frame-pointer -funroll-loops execution test
FAIL: gfortran.dg/realloc_on_assign_11.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/realloc_on_assign_11.f90 -O3 -g execution test
FAIL: gfortran.dg/realloc_on_assign_11.f90 -Os execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O1 execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O2 execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O3 -fomit-frame-pointer -funroll-loops execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -O3 -g execution test
FAIL: gfortran.dg/realloc_on_assign_7.f03 -Os execution test
The gfortran.dg/matmul_bounds_* are failures due to a change in the run time error (is there a good reason for that?) and the gfortran.dg/realloc_on_assign_* failures are due to segfaults at run time.
Dominique
>> Le 5 avr. 2015 à 22:37, Thomas Koenig <tkoenig@netcologne.de> a écrit :
>>
>> Hi Dominique,
>>
>>> which means that -fexternal-blas should disable the inlining.
>>
>> It is not surprising that a higly tuned BLAS library is better than
>> a simple inlining for large matrices.
>>
>> I did some tests by adjusting n; it seems the inline version is
>> faster for n<=22, which is not too bad.
>>
>> Regarding your other test case: This tests matrix*vector
>> multiplication, which is not implemented yet :-)
>>
>> Regards,
>>
>> Thomas
>
- References:
- Re: [patch, fortran, RFC] First steps towards inlining matmul
- From: Dominique Dhumieres
- Re: [patch, fortran, RFC] First steps towards inlining matmul
- Re: [patch, fortran, RFC] First steps towards inlining matmul
- From: Dominique d'Humières
- Re: [patch, fortran, RFC] First steps towards inlining matmul
- Re: [patch, fortran, RFC] First steps towards inlining matmul
- From: Dominique d'Humières