On 04/05/2015 08:35 PM, H.J. Lu wrote:
On Sun, Apr 5, 2015 at 6:44 PM, Sandra Loosemore
wrote:
[snip snip]
To tell the truth, I can't figure out what this means from a user
perspective. How does a user know whether the linker option is being
ignored, or if they have a new enough linker? If
On Sun, Apr 5, 2015 at 6:44 PM, Sandra Loosemore
wrote:
> On 04/03/2015 01:34 PM, Joseph Myers wrote:
>>
>> On Tue, 31 Mar 2015, Ilya Enkovich wrote:
>>
>>> +library. It also passes '-z bndplt' to a linker in case it supports
>>> this
>>> +option (which is checked on libmpx configuration). Note
On 04/03/2015 01:34 PM, Joseph Myers wrote:
On Tue, 31 Mar 2015, Ilya Enkovich wrote:
+library. It also passes '-z bndplt' to a linker in case it supports this
+option (which is checked on libmpx configuration). Note that old versions
+of linker may ignore option. Gold linker doesn't support
On Fri, 3 Apr 2015, Jonathan Wakely wrote:
> On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
> > On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
> > > Why then use __alignof(_M_i) (the object-alignment)
> > > instead of _S_alignment (the deduced alas insufficiently
> > > increased type-alignment)
The patch causes the following regressions:
FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (internal
compiler error)
FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (test for
excess errors)
FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=lib -O2 -lc
Hi,
The attached patch, type 0, has been discussed a little at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Yet, the final version submitted is slightly different from the ones discussed
and tested in the above link.
Having read the GNU Coding Conventions, I created a patch using svn di
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.
Regardi
Hi,
The attached patch, type 0, has been discussed a little at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Yet, the final version submitted is slightly different from the ones discussed
and tested in the above link.
Having read the GNU Coding Conventions, I created a patch using svn di
I have done some timings
(1) with the test given below, before the patch I get (last column in Gflops)
[Book15] f90/bug% gfc -Ofast timing/matmul_tst_sys.f90 -framework Accelerate
[Book15] f90/bug% time a.out
Time, MATMUL:373.708008 373.69497100014.2815668504139435
T
On 05/04/15 04:45 AM, Yvan Roux wrote:
Hi,
The issue is also present in 4.9 branch as explained in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
As 4.9 doesn't contains lra rematerialization passe, we only need to
stop updating lra_constraint_new_regno_start when inheritance is
switche
On Fri, 3 Apr 2015, Jan Hubicka wrote:
> -#ifdef ENABLE_CHECKING
> + /* This is used only for assert bellow. */
> +#if 0
"below" (instead of "bellow")
Gerald
Hi Dominique,
> IMO the inlining of MATMUL should be restricted to small matrices (less than
> 4x4, 9x9
> or 16x16 depending of your field!-)
The problem with the library function we have is that it is quite
general; it can deal with all the complexity of assumed-shape array
arguments. Inlining
> > So, what do you think about this?
>
> I am curious about what performance gain results from this?
> I can see saving a library call to our runtime libraries.
> Do you have some timing results?
>
> Jerry
IMO the inlining of MATMUL should be restricted to small matrices (less than
4x4, 9x9
or 1
Hi Jerry,
> I am curious about what performance gain results from this? I can see
> saving a library call to our runtime libraries. Do you have some timing
> results?
The speedup can be quite drastic for small matrices which can be
completely unrolled by -O3:
b1.f90:
program main
use b2
im
On 04/05/2015 05:32 AM, Thomas Koenig wrote:
--- snip ---
So, what do you think about this?
Thomas
I am curious about what performance gain results from this? I can see saving a
library call to our runtime libraries. Do you have some timing results?
Jerry
Hello world,
this is a first draft of a patch to inline matmul (PR 37171). This is
preliminary, but functional as far as it goes. Definitely for the
next stage one :-)
Basically, it takes
c = matmul(a,b)
and converts this into
BLOCK
integer i,j,k
c = 0
do j=0, size(b,2)-1
Dear Andre,
Well, time passed and it didn't get done. Too much going on at the moment!
As you say, the patch bootstraps and regtests on x86_64, FC21 in my case.
I am now very reluctant to mess around with the gcc-5 release. Thus, I
think that this patch must be committed to 5.2 and 6.0, when the
Hi,
The issue is also present in 4.9 branch as explained in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
As 4.9 doesn't contains lra rematerialization passe, we only need to
stop updating lra_constraint_new_regno_start when inheritance is
switched off.
Bootstrapped and tested on x64_64 a
18 matches
Mail list logo
