It seems that gfortran will inline MATMUL with optimization.
This produce very poor performance. In fact, gfortran will
inline MATMUL even if one specifies -fexternal-blas. This is
very bad.
% cat a.f90
program main
implicit none
integer, parameter :: imax = 2, jmax = 1
real,
Hi Steve,
I can confirm the bug (it's already in gcc 10) and will take a look
at it.
Regards
Thomas
Hi Paul, hi all fortran@/gcc-patch@ reader,
it looks as if you replied with your patch submission to the wrong email
address – and your re-submission ended up at https://gcc.gnu.org/PR99602#c17
On 16.03.21 18:08, Tobias Burnus wrote:
On 16.03.21 17:42, Paul Richard Thomas via Gcc-patches wrote:
*PING* of my 11.03.21 18:15 CET patch.
The issue is that the TREE_TYPE of the fndecl does not match its arglist.
In some cases, the middle end looks at the function type – and then it
goes wrong.
The issue only occurs for -fcoarray=lib as other hidden arguments are
properly handled.
Soluti
Fortran itself: suggestion is to add a new entry to the vtable
(breaking change) — thus, please also comment if you are not
interested in OpenMP (or coarrays).
For OpenMP: When mapping a derived-type to a non-shared-memory
(accelerator/GPU) device, it gets complicated with (polymorphic)
allocatab
On Thu, Mar 18, 2021 at 8:49 AM Steve Kargl via Fortran
wrote:
>
> It seems that gfortran will inline MATMUL with optimization.
> This produce very poor performance. In fact, gfortran will
> inline MATMUL even if one specifies -fexternal-blas. This is
> very bad.
>
> % cat a.f90
> program main
Hi Tobias,
Thanks for the review. I am resisting dg-run for this patch simply because
the testsuite already takes an oppressive amount of time to run. That the
runtime error is present in the code should be sufficient IMHO.
Regards
Paul
On Thu, 18 Mar 2021 at 08:46, Tobias Burnus wrote:
> Hi
Richard,
On 18.03.21 13:35, Richard Biener via Fortran wrote:
[...]
Since the libgfortran MATMUL should be vectorized
I think it's not reasonable to inline any but _very_ small
MATMUL at optimization levels that do not enable vectorization.
Besides the obvious if (!flag_external_blas) which sh
On Thu, Mar 18, 2021 at 3:48 PM Tobias Burnus wrote:
>
> Richard,
>
> On 18.03.21 13:35, Richard Biener via Fortran wrote:
> > [...]
> > Since the libgfortran MATMUL should be vectorized
> > I think it's not reasonable to inline any but _very_ small
> > MATMUL at optimization levels that do not en
On Thu, Mar 18, 2021 at 04:05:40PM +0100, Richard Biener wrote:
> On Thu, Mar 18, 2021 at 3:48 PM Tobias Burnus wrote:
> >
> > Richard,
> >
> > On 18.03.21 13:35, Richard Biener via Fortran wrote:
> > > [...]
> > > Since the libgfortran MATMUL should be vectorized
> > > I think it's not reasonable
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail before: This is a vector-matrix
operation.
For this, we do not have a good library routine (Harald just
removed it because of a bug in buffering), and -fexternal-blas
does not work because we do no
I didn't finish the previous mail before hitting "send", so here
is the postscript...
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail before: This is a vector-matrix
operation.
For this, we do not have a good library routine (Harald just
remov
On Thu, Mar 18, 2021 at 07:24:21PM +0100, Thomas Koenig wrote:
> I didn't finish the previous mail before hitting "send", so here
> is the postscript...
>
> > OK, so I've had a bit of time to look at the actual test case. I
> > missed one very important detail before: This is a vector-matrix
> >
Am 18.03.21 um 21:22 schrieb Steve Kargl:
On Thu, Mar 18, 2021 at 07:24:21PM +0100, Thomas Koenig wrote:
I didn't finish the previous mail before hitting "send", so here
is the postscript...
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail be
On Thu, Mar 18, 2021 at 09:55:27PM +0100, Thomas Koenig wrote:
>
> > I haven't checked. If so, how about disabling
> > in-lining MATMUL for 11.1;
>
> Absolutely not for the general case. This would cause a huge regression
> in execution time for 2*2 matrices, and also for small matrix-vector
> m
Hi Steve,
On my old core2 cpu, a quick test with N=1000 and NxN matrix
suggest a cross over near N=1000 for REAL(4). This cpu doesn't
have any AVX* instruction, so YMMV. Program follows .sig
Looking at your data with AVX (which I think we can mostly count
on now),
- The library is always
Am 19.03.21 um 07:19 schrieb Thomas Koenig:
I'll work on a patch.
So, here's a concept patch. It still needs a ChangeLog and testsuite
adjustment, but this is what I would propose to use.
Regards
Thomas
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
inde
17 matches
Mail list logo