Re: Read-only *.ali files in adalib installation?
> I built an Ada cross-compiler and noticed that all the *.ali files in > adalib are read-only, e.g. > > ll /opt/rtems-4.12/lib64/gcc/powerpc-rtems4.12/7.1.1/adalib/ > > [...] > > -r--r--r-- 1 sebastian_h domain users 5210 Jun 12 14:06 i-fortra.ali > -r--r--r-- 1 sebastian_h domain users 2769 Jun 12 14:06 interfac.ali > -r--r--r-- 1 sebastian_h domain users 805 Jun 12 14:06 ioexcept.ali > -r--r--r-- 1 sebastian_h domain users 4179 Jun 12 14:06 i-pacdec.ali > -rw-r--r-- 1 sebastian_h domain users 1450556 Jun 12 14:30 libgnarl.a > -rw-r--r-- 1 sebastian_h domain users 16076716 Jun 12 14:30 libgnat.a > > [...] > > This is unlike the lib*.a files, which are user writeable. Its this > intentional? Yes for the ALI files, but no for the libraries (it doesn't matter for them). -- Eric Botcazou
backtrace.h not installed with --enable-plugin
Hello All, I compiled a gcc-7.1 release tree configured with '../gcc-7.1.0/configure' '--program-suffix=-7my' '--enable-shared' '--enable-linker-build-id' '--without-included-gettext' '--enable-threads=posix' '--with-sysroot=/' '--enable-clocale=gnu' '--enable-libstdcxx-debug' '--enable-libstdcxx-time=yes' '--with-default-libstdcxx-abi=new' '--enable-gnu-unique-object' '--enable-libmpx' '--enable-plugin' '--enable-default-pie' '--with-system-zlib' '--enable-multiarch' '--with-arch-32=i686' '--with-abi=m64' '--with-multilib-list=m32,m64,mx32' '--enable-multilib' '--with-tune=native' '--enable-checking=release' '--enable-languages=c,c++,go,lto' I was expecting the installed built tree to contain the backtrace.h from Ian Taylor's libbacktrace. This is not the case. Why? What configure option did I miss? notice that ../gcc-7.1.0/configure --help don't mention backtrace (is that a bug, perhaps at least in the documentation or in ../gcc-7.1.0/configure.ac ?? Or am I misunderstanding something??) Regards -- Basile Starynkevitch (France) http://starynkevitch.net/Basile/
Re: backtrace.h not installed with --enable-plugin
On Wed, Jun 14, 2017 at 9:08 AM, wrote: > Hello All, > > I compiled a gcc-7.1 release tree configured with > > '../gcc-7.1.0/configure' '--program-suffix=-7my' '--enable-shared' > '--enable-linker-build-id' '--without-included-gettext' > '--enable-threads=posix' '--with-sysroot=/' '--enable-clocale=gnu' > '--enable-libstdcxx-debug' '--enable-libstdcxx-time=yes' > '--with-default-libstdcxx-abi=new' '--enable-gnu-unique-object' > '--enable-libmpx' '--enable-plugin' '--enable-default-pie' > '--with-system-zlib' '--enable-multiarch' '--with-arch-32=i686' > '--with-abi=m64' '--with-multilib-list=m32,m64,mx32' '--enable-multilib' > '--with-tune=native' '--enable-checking=release' > '--enable-languages=c,c++,go,lto' > > I was expecting the installed built tree to contain the backtrace.h from Ian > Taylor's libbacktrace. This is not the case. Why? What configure option did > I miss? libbacktrace is a convenience library only and is not installed so why do you expect backtrace.h to be installed? > notice that ../gcc-7.1.0/configure --help don't mention backtrace > > (is that a bug, perhaps at least in the documentation or in > ../gcc-7.1.0/configure.ac ?? Or am I misunderstanding something??) > > Regards > -- > Basile Starynkevitch (France) http://starynkevitch.net/Basile/
Optimization for static local variables
I'm developing a solution to optimize away intermediate stores (loads) for
static local variables which are assigned to before referenced on every path
through a function.
Currently GCC eliminates all loads/stores in a straight line code but not in
control structures. AFAIU, passes like sccvn, lim (store motion in particular)
sink etc. try to propagate the assignment exprs through SSA vars instead of
through memory thereby eliminating almost all loads and some stores but still
not all.
For example:
void some_function()
{
static some_type sum;
...
for( i = 0 ; i < n ; i++ )
{
sum = matrix [i][n] ;
for( j = 0 ; j < i ; j++ )
{
sum -= matrix [i][j] * matrix [j][n] ;
}
matrix [i][n] = sum ;
}
...
}
Resulting SSA:
...
[2.25%]:
_10 = matrix[0][n_13(D)];
sum = _10;
goto ; [100.00%]
...
[12.75%]:
_1 = matrix[i_16][n_13(D)];
if (i_16 > 0)
goto ; [100.00%]
else
goto ; [0.00%]
...
[85.00%]:
# j_24 = PHI
# sum_lsm.4_27 = PHI <_6(6), _1(4)>
_3 = matrix[i_16][j_24];
_4 = matrix[j_24][n_13(D)];
_5 = _3 * _4;
_6 = sum_lsm.4_27 - _5;
j_18 = j_24 + 1;
if (i_16 > j_18)
goto ; [85.00%]
else
goto ; [15.00%]
...
[12.75%]:
# _40 = PHI <_6(6)>
goto ; [100.00%]
[12.75%]:
# sum_lsm.4_19 = PHI <_40(7), _1(4)>
[15.00%]:
# i_20 = PHI
# sum_lsm.4_8 = PHI
# sum_lsm.5_22 = PHI <1(9), 0(14)>
matrix[i_20][n_13(D)] = sum_lsm.4_8;
i_16 = i_20 + 1;
if (n_13(D) > i_16)
goto ; [85.00%]
else
goto ; [15.00%]
[2.25%]:
# sum_lsm.4_39 = PHI
# sum_lsm.5_38 = PHI
if (sum_lsm.5_38 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[0.00%]:
sum = sum_lsm.4_39;
...
Although all intermediate loads are eliminated here, store to sum before and
after the 'j' loop (see bb 14 and bb 12) still remain which can be eliminated.
My solution would reuse a lot of data structures and routines from the sink
pass. So my question is, can I add this optimization into the sink pass itself
or would it require a new pass and if yes, what would be the ideal place for it.
Any other pointers are more than welcome.
Thanks,
Prachi
Re: Optimization for static local variables
On Wed, Jun 14, 2017 at 12:14 PM, Prachi Godbole
wrote:
> I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
>
> Currently GCC eliminates all loads/stores in a straight line code but not in
> control structures. AFAIU, passes like sccvn, lim (store motion in
> particular) sink etc. try to propagate the assignment exprs through SSA vars
> instead of through memory thereby eliminating almost all loads and some
> stores but still not all.
>
> For example:
>
> void some_function()
> {
> static some_type sum;
> ...
> for( i = 0 ; i < n ; i++ )
> {
> sum = matrix [i][n] ;
>
> for( j = 0 ; j < i ; j++ )
> {
> sum -= matrix [i][j] * matrix [j][n] ;
> }
>
> matrix [i][n] = sum ;
> }
> ...
> }
>
> Resulting SSA:
>
> ...
>[2.25%]:
> _10 = matrix[0][n_13(D)];
> sum = _10;
> goto ; [100.00%]
> ...
>[12.75%]:
> _1 = matrix[i_16][n_13(D)];
> if (i_16 > 0)
> goto ; [100.00%]
> else
> goto ; [0.00%]
> ...
>[85.00%]:
> # j_24 = PHI
> # sum_lsm.4_27 = PHI <_6(6), _1(4)>
> _3 = matrix[i_16][j_24];
> _4 = matrix[j_24][n_13(D)];
> _5 = _3 * _4;
> _6 = sum_lsm.4_27 - _5;
> j_18 = j_24 + 1;
> if (i_16 > j_18)
> goto ; [85.00%]
> else
> goto ; [15.00%]
> ...
>[12.75%]:
> # _40 = PHI <_6(6)>
> goto ; [100.00%]
>
>[12.75%]:
> # sum_lsm.4_19 = PHI <_40(7), _1(4)>
>
>[15.00%]:
> # i_20 = PHI
> # sum_lsm.4_8 = PHI
> # sum_lsm.5_22 = PHI <1(9), 0(14)>
> matrix[i_20][n_13(D)] = sum_lsm.4_8;
> i_16 = i_20 + 1;
> if (n_13(D) > i_16)
> goto ; [85.00%]
> else
> goto ; [15.00%]
>
>[2.25%]:
> # sum_lsm.4_39 = PHI
> # sum_lsm.5_38 = PHI
> if (sum_lsm.5_38 != 0)
> goto ; [0.00%]
> else
> goto ; [100.00%]
>
>[0.00%]:
> sum = sum_lsm.4_39;
> ...
>
> Although all intermediate loads are eliminated here, store to sum before and
> after the 'j' loop (see bb 14 and bb 12) still remain which can be eliminated.
It looks like dead store elimination to sum. Maybe static local
variable can be better handled there?
Thanks,
bin
>
> My solution would reuse a lot of data structures and routines from the sink
> pass. So my question is, can I add this optimization into the sink pass
> itself or would it require a new pass and if yes, what would be the ideal
> place for it.
> Any other pointers are more than welcome.
>
> Thanks,
> Prachi
Re: Optimization for static local variables
On Wed, Jun 14, 2017 at 1:14 PM, Prachi Godbole
wrote:
> I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
>
> Currently GCC eliminates all loads/stores in a straight line code but not in
> control structures. AFAIU, passes like sccvn, lim (store motion in
> particular) sink etc. try to propagate the assignment exprs through SSA vars
> instead of through memory thereby eliminating almost all loads and some
> stores but still not all.
>
> For example:
>
> void some_function()
> {
> static some_type sum;
> ...
> for( i = 0 ; i < n ; i++ )
> {
> sum = matrix [i][n] ;
>
> for( j = 0 ; j < i ; j++ )
> {
> sum -= matrix [i][j] * matrix [j][n] ;
> }
>
> matrix [i][n] = sum ;
> }
> ...
> }
>
> Resulting SSA:
>
> ...
>[2.25%]:
> _10 = matrix[0][n_13(D)];
> sum = _10;
> goto ; [100.00%]
> ...
>[12.75%]:
> _1 = matrix[i_16][n_13(D)];
> if (i_16 > 0)
> goto ; [100.00%]
> else
> goto ; [0.00%]
> ...
>[85.00%]:
> # j_24 = PHI
> # sum_lsm.4_27 = PHI <_6(6), _1(4)>
> _3 = matrix[i_16][j_24];
> _4 = matrix[j_24][n_13(D)];
> _5 = _3 * _4;
> _6 = sum_lsm.4_27 - _5;
> j_18 = j_24 + 1;
> if (i_16 > j_18)
> goto ; [85.00%]
> else
> goto ; [15.00%]
> ...
>[12.75%]:
> # _40 = PHI <_6(6)>
> goto ; [100.00%]
>
>[12.75%]:
> # sum_lsm.4_19 = PHI <_40(7), _1(4)>
>
>[15.00%]:
> # i_20 = PHI
> # sum_lsm.4_8 = PHI
> # sum_lsm.5_22 = PHI <1(9), 0(14)>
> matrix[i_20][n_13(D)] = sum_lsm.4_8;
> i_16 = i_20 + 1;
> if (n_13(D) > i_16)
> goto ; [85.00%]
> else
> goto ; [15.00%]
>
>[2.25%]:
> # sum_lsm.4_39 = PHI
> # sum_lsm.5_38 = PHI
> if (sum_lsm.5_38 != 0)
> goto ; [0.00%]
> else
> goto ; [100.00%]
>
>[0.00%]:
> sum = sum_lsm.4_39;
> ...
>
> Although all intermediate loads are eliminated here, store to sum before and
> after the 'j' loop (see bb 14 and bb 12) still remain which can be eliminated.
>
> My solution would reuse a lot of data structures and routines from the sink
> pass. So my question is, can I add this optimization into the sink pass
> itself or would it require a new pass and if yes, what would be the ideal
> place for it.
> Any other pointers are more than welcome.
So the idea is that for any store to such variable that is dominated
by a kill the function exit doesn't count as a use, right?
(unless the variable escapes the scope of the function, for example
via a nested function -- which might be the case that
is very difficult to detect).
I'm not sure what part of the sink pass is suitable for this but as
sinking walks post dominators backwards which also DSE
does it would fit DSE as well, no? You'd pre-compute blocks
containing kills (or do two backwards passes) and then
special case GIMPLE_RETURN in dse_classify_store where previously
ref_maybe_used_by_stmt_p covers those.
nested fn case:
void foo (void)
{
static int i = 0;
int __attribute__((noinline)) bar () { return i; }
int j = bar ();
i = 1;
}
I think we don't mark 'i' TREE_ADDRESSABLE (escaped) here so we simply
treat 'i' as a global variable accessible
from other scopes.
Richard.
> Thanks,
> Prachi
RE: Optimization for static local variables
> On Wed, Jun 14, 2017 at 1:14 PM, Prachi Godbole
> wrote:
> > I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
> >
> > Currently GCC eliminates all loads/stores in a straight line code but not in
> control structures. AFAIU, passes like sccvn, lim (store motion in particular)
> sink etc. try to propagate the assignment exprs through SSA vars instead of
> through memory thereby eliminating almost all loads and some stores but
> still not all.
> >
> > For example:
> >
> > void some_function()
> > {
> > static some_type sum;
> > ...
> > for( i = 0 ; i < n ; i++ )
> > {
> > sum = matrix [i][n] ;
> >
> > for( j = 0 ; j < i ; j++ )
> > {
> > sum -= matrix [i][j] * matrix [j][n] ;
> > }
> >
> > matrix [i][n] = sum ;
> > }
> > ...
> > }
> >
> > Resulting SSA:
> >
> > ...
> >[2.25%]:
> > _10 = matrix[0][n_13(D)];
> > sum = _10;
> > goto ; [100.00%]
> > ...
> >[12.75%]:
> > _1 = matrix[i_16][n_13(D)];
> > if (i_16 > 0)
> > goto ; [100.00%]
> > else
> > goto ; [0.00%]
> > ...
> >[85.00%]:
> > # j_24 = PHI
> > # sum_lsm.4_27 = PHI <_6(6), _1(4)>
> > _3 = matrix[i_16][j_24];
> > _4 = matrix[j_24][n_13(D)];
> > _5 = _3 * _4;
> > _6 = sum_lsm.4_27 - _5;
> > j_18 = j_24 + 1;
> > if (i_16 > j_18)
> > goto ; [85.00%]
> > else
> > goto ; [15.00%]
> > ...
> >[12.75%]:
> > # _40 = PHI <_6(6)>
> > goto ; [100.00%]
> >
> >[12.75%]:
> > # sum_lsm.4_19 = PHI <_40(7), _1(4)>
> >
> >[15.00%]:
> > # i_20 = PHI
> > # sum_lsm.4_8 = PHI
> > # sum_lsm.5_22 = PHI <1(9), 0(14)>
> > matrix[i_20][n_13(D)] = sum_lsm.4_8;
> > i_16 = i_20 + 1;
> > if (n_13(D) > i_16)
> > goto ; [85.00%]
> > else
> > goto ; [15.00%]
> >
> >[2.25%]:
> > # sum_lsm.4_39 = PHI
> > # sum_lsm.5_38 = PHI
> > if (sum_lsm.5_38 != 0)
> > goto ; [0.00%]
> > else
> > goto ; [100.00%]
> >
> >[0.00%]:
> > sum = sum_lsm.4_39;
> > ...
> >
> > Although all intermediate loads are eliminated here, store to sum before
> and after the 'j' loop (see bb 14 and bb 12) still remain which can be
> eliminated.
> >
> > My solution would reuse a lot of data structures and routines from the sink
> pass. So my question is, can I add this optimization into the sink pass
> itself or
> would it require a new pass and if yes, what would be the ideal place for it.
> > Any other pointers are more than welcome.
>
> So the idea is that for any store to such variable that is dominated by a
> kill the
> function exit doesn't count as a use, right?
> (unless the variable escapes the scope of the function, for example via a
> nested function -- which might be the case that is very difficult to detect).
>
Yes that is the general idea. I had thought of initially being conservative and
not optimizing at all when the variable could potentially escape the scope.
> I'm not sure what part of the sink pass is suitable for this but as sinking
> walks
> post dominators backwards which also DSE does it would fit DSE as well, no?
> You'd pre-compute blocks containing kills (or do two backwards passes) and
> then special case GIMPLE_RETURN in dse_classify_store where previously
> ref_maybe_used_by_stmt_p covers those.
>
I was looking for a one time solution rather than doing it as and when the
opportunities present themselves.
But doing it in DSE is more advantageous, I can see that. So I'll go ahead with
DSE.
> nested fn case:
>
> void foo (void)
> {
> static int i = 0;
> int __attribute__((noinline)) bar () { return i; }
> int j = bar ();
> i = 1;
> }
>
> I think we don't mark 'i' TREE_ADDRESSABLE (escaped) here so we simply
> treat 'i' as a global variable accessible from other scopes.
>
> Richard.
>
> > Thanks,
> > Prachi
Re: [PATCH] Recognize '-' as special -MF argument (write to stdout)
Thanks, I've tested this patch for x86_64-pc-linux-gnu and committed it to trunk. As a new feature it doesn't seem appropriate for release branches. -- Joseph S. Myers jos...@codesourcery.com
gcc-6-20170614 is now available
Snapshot gcc-6-20170614 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170614/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 249206 You'll find: gcc-6-20170614.tar.xzComplete GCC SHA256=ec36462b9a8388accca91ffae190eb696e5fade4a5e1c573be349448ee4b31ac SHA1=f48f10787e29c42dad76ab8eedfc6d34fc3ab637 Diffs from 6-20170607 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
