Re: -g and -fvar-tracking
On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote: > Can somebody remind me why using -g doesn't also enable -fvar-tracking by > default? At least for -g2, which is supposed to emit debug information > about local variables? It seems kind of counterintuitive to me that > specifying a -O option enables a pass to collect better debug information > but specifying -g to request debuggable code doesn't. :-S Because var-tracking is compile time expensive and for -O0 not needed in most cases (variable live in memory). It would be nice to have only partial fast var-tracking for -O0, that would track only variables that don't live in memory or say parameters before they are assigned to their slots or similarly VLAs before they make it into their slots. That said, for -O0 it would need to be really fast. We also have -Og which is supposed to provide good debugging experience while optimizing a little, the worst problem with that is that in -Og we don't artificially extend lifetime of variables till end of their scope, so if some value is not needed after some point in the middle of the scope, then if there is no way to compute that value anymore we can't provide the value. Jakub
Re: Loop fusion.
On Mon, Apr 23, 2018 at 8:35 PM, Toon Moene wrote: > On 04/23/2018 01:00 PM, Richard Biener wrote: > >> On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene wrote: >>> >>> A few days ago there was a rant on the Fortran Standardization >>> Committee's >>> e-mail list about Fortran's "whole array arithmetic" being unoptimizable. >>> >>> An example picked at random from our weather forecasting code: >>> >>> ZQICE(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YI%MP) >>> ZQLI(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YL%MP) >>> ZQRAIN(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YR%MP) >>> ZQSNOW(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YS%MP) >>> >>> The reaction from one of the members of the committee (about "their" >>> compiler): >>> >>> 'And multiple consecutive array statements with the same shape are >>> “fused” >>> exactly so that the compiler can generate good cache use. This sort of >>> optimization is pretty low hanging fruit.' >>> >>> As far as I can see loop fusion as a stand-alone optimization is not >>> supported as yet, although some mention is made in the context of >>> graphite. >>> >>> Is this something that should be pursued ? >> >> >> In principle GRAPHITE can handle loop fusion but yes, standalone fusion >> is sth useful. >> >> Note that while it looks "obvious" in the above source fragment the IL >> that is presented to optimizers may make things a lot less "low-hanging". > > > Well, the loops are generated by the front end, so I *assume* they are > basically the same ... The issue will be boiler-plate code like duplicated loop header checks. That said, it's perfectly understandable that other Fortran compilers have high-level loop opts deeply embedded within their frontends... > Probably the largest problem to address is the heuristic for preventing > register pressure going through the roof ... Yes. As Bin said loop fusion and fission are closely related and should share their cost modeling - they both have the goal to optimize the number of input and output memory streams and their re-use within the constraints of the CPU architecture (which includes number of available registers). Note that the difficulty with fusion compared to fission is that our dependence analysis framework cannot handle the case of sibling loops (as required by fusion). So we have to either apply some "tricks" to use the current framework or move over to more capable dependence testing infrastructure like that of ISL. Richard. > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
Hello, I am pleased to announce that Hrishikesh Kulkarni will be working on "Textual Representation of LTO Object Files (Textual LTO dump tool project)" as his Google Summer of Code 2018 project. I believe I write on behalf of everybody in the GCC community when I congratulate him and wish him success in the upcoming work. Hrishikesh's mentors are Martin Liška and Jan Hubička, but the plan is to have most of the conversation about the project on the mailing list and so I would like to encourage everyone to help him out here if they can. According to the schedule of GSoC, we have entered "Community Bonding period" which lasts until May 14th (when the first out of three "coding" periods begin). Hrishikesh, Martin and Honza will take over from me in suggesting what technical things you should study/play with, but I'd like to request that you make sure you get an FSF copyright assignment quickly (see https://gcc.gnu.org/contribute.html#legal). David, I assume that Hrishikesh does not have the assignment yet, can you please send him the necessary forms? Hrishikesh, please fill them is when you get and send them to FSF. If at any moment it will appear that the process got stuck, please let me know sooner rather than later. On a general note, GCC was given two student slots which we requested after receiving two high-quality student proposals. Unfortunately, Sebastiaan has withdrawn from GSoC 2018 before selection was announced and so we "only" have one student this year. I'm looking forward to the new tool, Martin
RFC: bash completion
Hi.
Some time ago, I investigated quite new feature of clang which
is support of --autocomplete argument. That can be run from bash completion
script and one gets more precise completion hints:
http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
https://www.youtube.com/watch?v=zLPwPdZBpSY
I like the idea and I would describe how is that better to current GCC
completion
script sitting here:
https://github.com/scop/bash-completion/blob/master/completions/gcc
1) gcc -fsanitize=^ - no support for option enum values
2) gcc -fno-sa^ - no support for negative options
3) gcc --param=^ - no support for param names
These are main limitations I see. I'm attaching working prototype, which you
can test by installed GCC, setting it on $PATH and doing:
$ source gcc.sh
Then bash completion is provided via the newly added option. Some examples:
1)
$ gcc -fsanitize=
addressbounds enum
integer-divide-by-zero nonnull-attribute pointer-compare
return shift-base thread
vla-bound
alignment bounds-strict float-cast-overflow
kernel-address null pointer-overflow
returns-nonnull-attribute shift-exponent undefined
vptr
bool builtinfloat-divide-by-zero
leak object-sizepointer-subtract
shift signed-integer-overflowunreachable
2)
$ gcc -fno-ipa-
-fno-ipa-bit-cp -fno-ipa-cp-alignment -fno-ipa-icf
-fno-ipa-icf-variables -fno-ipa-profile-fno-ipa-pure-const
-fno-ipa-reference -fno-ipa-struct-reorg
-fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf-functions
-fno-ipa-matrix-reorg -fno-ipa-pta-fno-ipa-ra
-fno-ipa-sra-fno-ipa-vrp
3)
$ gcc --param=lto-
lto-max-partition lto-min-partition lto-partitions
4)
gcc --param lto-
lto-max-partition lto-min-partition lto-partitions
The patch is quite lean and if people like, I will prepare a proper
patch submission. I know about some limitations that can be then
handled incrementally.
Thoughts?
Martin
>From 7bf882961cd81d3f12df017398625ee190c9808f Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 23 Feb 2018 12:28:43 +0100
Subject: [PATCH] First version of prototype.
---
gcc.sh | 51 +++
gcc/common.opt | 4
gcc/gcc.c | 48
gcc/gcc.h | 1 +
gcc/opts.c | 3 +++
gcc/params.c | 13 +
gcc/params.h | 1 +
7 files changed, 121 insertions(+)
create mode 100644 gcc.sh
diff --git a/gcc.sh b/gcc.sh
new file mode 100644
index 000..06b16b3152b
--- /dev/null
+++ b/gcc.sh
@@ -0,0 +1,51 @@
+# Please add "source /path/to/bash-autocomplete.sh" to your .bashrc to use this.
+
+log()
+{
+ echo $1 >> /tmp/bash-completion.log
+}
+
+_gcc()
+{
+local cur prev prev2 words cword argument prefix
+_init_completion || return
+_expand || return
+
+# extract also for situations like: -fsanitize=add
+if [[ $cword > 2 ]]; then
+ prev2="${COMP_WORDS[$cword - 2]}"
+fi
+
+log "cur: '$cur', prev: '$prev': prev2: '$prev2' cword: '$cword'"
+
+# sample: -fsan
+if [[ "$cur" == -* ]]; then
+ argument=$cur
+# sample: -fsanitize=
+elif [[ "$cur" == "=" && $prev == -* ]]; then
+ argument=$prev$cur
+ prefix=$prev$cur
+# sample: -fsanitize=add
+elif [[ "$prev" == "=" && $prev2 == -* ]]; then
+ argument=$prev2$prev$cur
+ prefix=$prev2$prev
+# sample: --param lto-
+elif [[ "$prev" == "--param" ]]; then
+ argument="$prev $cur"
+ prefix="$prev "
+fi
+
+log "argument: '$argument', prefix: '$prefix'"
+
+if [[ "$argument" == "" ]]; then
+ _filedir
+else
+ # In situation like '-fsanitize=add' $cur is equal to last token.
+ # Thus we need to strip the beginning of suggested option.
+ flags=$( gcc --completion="$argument" 2>/dev/null | sed "s/^$prefix//")
+ log "compgen: $flags"
+ [[ "${flags: -1}" == '=' ]] && compopt -o nospace 2> /dev/null
+ COMPREPLY=( $( compgen -W "$flags" -- "") )
+fi
+}
+complete -F _gcc gcc
diff --git a/gcc/common.opt b/gcc/common.opt
index d6ef85928f3..389d4fa0385 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -254,6 +254,10 @@ Driver Alias(S)
-compile
Driver Alias(c)
+-completion=
+Common Driver Joined
+--param Bash completion.
+
-coverage
Driver Alias(coverage)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index a716f708259..dab88f44d27 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -220,6 +220,8 @@ static int print_help_list;
static int print_version;
+static const char *completion
Re: r9 on ARM32?
On 24/04/18 03:22, Jay K wrote: > I'm wondering what is the role of r9 on ARM32, on Linux and Android. It's another callee-saved register and has no other special purpose. This is defined in the https://sourcery.mentor.com/GNUToolchain/kbattach142/arm_gnu_linux_abi.pdf which is the linux-specific platform binding information for the ARM EABI (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html) R. > On Apple it is documented as long ago reserved, these days available for > scratch. > > I've looked around a bit but haven't gotten the full answer. > > It is "the PIC register", I see. > > What does that imply? Volatile? Von-volatile? > > In particular I'm looking for a spare register, to pass an extra "special" > parameter in, that can be considered volatile and never otherwise has a > parameter. > > Most ABIs have a few candidates, but arm32 comes up relatively short. > > Intra procedural scratch (r12) probably cannot work for me. > I know gcc uses it for nested function context and that is laudable. I wish I > could guarantee no code between me setting it and it being consumed. > > And if it is volatile, I'd want the dynamic linker stubs to still preserve it > incoming. > > Thank you, > - Jay >
Re: RFC: bash completion
On Tue, 2018-04-24 at 16:45 +0200, Martin Liška wrote:
> Hi.
>
> Some time ago, I investigated quite new feature of clang which
> is support of --autocomplete argument. That can be run from bash
> completion
> script and one gets more precise completion hints:
>
> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.htm
> l
> https://www.youtube.com/watch?v=zLPwPdZBpSY
>
> I like the idea and I would describe how is that better to current
> GCC completion
> script sitting here:
> https://github.com/scop/bash-completion/blob/master/completions/gcc
>
> 1) gcc -fsanitize=^ - no support for option enum values
> 2) gcc -fno-sa^ - no support for negative options
> 3) gcc --param=^ - no support for param names
>
> These are main limitations I see. I'm attaching working prototype,
> which you
> can test by installed GCC, setting it on $PATH and doing:
> $ source gcc.sh
>
> Then bash completion is provided via the newly added option. Some
> examples:
>
> 1)
> $ gcc -fsanitize=
> addressbounds enum
> integer-divide-by-zero nonnull-
> attribute pointer-
> comparereturn shift-
> base thread vla-bound
> alignment bounds-strict float-cast-
> overflowkernel-
> address null pointer-
> overflow returns-nonnull-attribute shift-
> exponent undefined vptr
> bool builtinfloat-divide-
> by-zero leak object-
> sizepointer-
> subtract shift signed-integer-
> overflowunreachable
>
> 2)
> $ gcc -fno-ipa-
> -fno-ipa-bit-cp -fno-ipa-cp-alignment -fno-ipa-
> icf-fno-ipa-icf-variables -fno-ipa-profile-fno-
> ipa-pure-const -fno-ipa-reference -fno-ipa-struct-reorg
> -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf-
> functions -fno-ipa-matrix-reorg -fno-ipa-pta-fno-ipa-
> ra -fno-ipa-sra-fno-ipa-vrp
>
> 3)
> $ gcc --param=lto-
> lto-max-partition lto-min-partition lto-partitions
>
> 4)
> gcc --param lto-
> lto-max-partition lto-min-partition lto-partitions
>
> The patch is quite lean and if people like, I will prepare a proper
> patch submission. I know about some limitations that can be then
> handled incrementally.
>
> Thoughts?
> Martin
Overall, looks good (albeit with various nits). I like how you're
reusing the m_option_suggestions machinery from the misspelled options
code. There are some awkward issues e.g. arch-specific completions,
lang-specific completions, custom option-handling etc, but given that
as-is this patch seems to be an improvement over the status quo, I'd
prefer to tackle those later.
The patch doesn't have tests. There would need to be some way to
achieve test coverage for the completion code (especially as we start
to tackle the more interesting cases). I wonder what the best way to
do that is; perhaps a combination of selftest and DejaGnu? (e.g. what
about arch-specific completions? what about the interaction with bash?
etc)
A few nits:
* Do we want to hardcode that logging path in gcc.sh?
* Looks like m_option_suggestions isn't needed for handling the "-
param" case, so maybe put the param-handling case before the "Lazily
populate m_option_suggestions" code.
* You use "l" ("ell") as a variable name in two places, which I don't
like, as IMHO it's too close to "1" (one) in some fonts.
Thanks
Dave
Re: -g and -fvar-tracking
On 04/24/2018 01:05 AM, Jakub Jelinek wrote:
On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote:
Can somebody remind me why using -g doesn't also enable -fvar-tracking by
default? At least for -g2, which is supposed to emit debug information
about local variables? It seems kind of counterintuitive to me that
specifying a -O option enables a pass to collect better debug information
but specifying -g to request debuggable code doesn't. :-S
Because var-tracking is compile time expensive and for -O0 not needed in
most cases (variable live in memory). It would be nice to have only partial
fast var-tracking for -O0, that would track only variables that don't live
in memory or say parameters before they are assigned to their slots or
similarly VLAs before they make it into their slots. That said, for -O0 it
would need to be really fast.
Hmmm. There is a GDB test case (gdb.base/store.c) that is doing:
charest
wack_charest (register charest u, register charest v)
{
register charest l = u, r = v;
l = add_charest (l, r);
return l + r;
}
and expecting l and r to have meaningful debug information. If GCC
can't produce it with just -g and that is intentional behavior, then it
sounds like the GDB test case needs to be either fixed or XFAILed. The
specific failure we're seeing is that r's debug information is pointing
only at its initial location in a call-clobbered register, even though
it's moved to a different place before the call. With -fvar-tracking it
produces better debug information, and with any kind of optimization
enabled it produces better code. :-P
We also have -Og which is supposed to provide good debugging experience
while optimizing a little, the worst problem with that is that in -Og we
don't artificially extend lifetime of variables till end of their scope, so
if some value is not needed after some point in the middle of the scope,
then if there is no way to compute that value anymore we can't provide the
value.
TBH I'm personally more inclined to use just -O rather than -Og for
building code for hand debugging. But it looks like the GDB testsuite
builds its test programs with -g only by default.
-Sandra
Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
Hi, Thanks a lot for giving me this wonderful opportunity to work with GCC under your guidance and mentorship (GSOC 2018). Just a few starting queries 1. As a starting point to read lto-object file, is it sufficient to only link with lto-object.c or shall I need other source files too ? 2. Should the dump tool be under gcc or lto dir? Would I need to modify only gcc/Makefile.in to add entry for building the dump tool or any other Makefiles too ? Also, I would proceed with copyright assignment as soon as I will receive the mentioned forms. Thanks, Hrishikesh On Tue, Apr 24, 2018 at 6:27 PM, Martin Jambor wrote: > Hello, > > I am pleased to announce that Hrishikesh Kulkarni will be working on > "Textual Representation of LTO Object Files (Textual LTO dump tool > project)" as his Google Summer of Code 2018 project. I believe I write > on behalf of everybody in the GCC community when I congratulate him and > wish him success in the upcoming work. Hrishikesh's mentors are Martin > Liška and Jan Hubička, but the plan is to have most of the conversation > about the project on the mailing list and so I would like to encourage > everyone to help him out here if they can. > > According to the schedule of GSoC, we have entered "Community Bonding > period" which lasts until May 14th (when the first out of three "coding" > periods begin). Hrishikesh, Martin and Honza will take over from me in > suggesting what technical things you should study/play with, but I'd > like to request that you make sure you get an FSF copyright assignment > quickly (see https://gcc.gnu.org/contribute.html#legal). David, I > assume that Hrishikesh does not have the assignment yet, can you please > send him the necessary forms? Hrishikesh, please fill them is when you > get and send them to FSF. If at any moment it will appear that the > process got stuck, please let me know sooner rather than later. > > On a general note, GCC was given two student slots which we requested > after receiving two high-quality student proposals. Unfortunately, > Sebastiaan has withdrawn from GSoC 2018 before selection was announced > and so we "only" have one student this year. > > I'm looking forward to the new tool, > > Martin >
Re: Loop fusion.
On 04/24/2018 09:18 AM, Richard Biener wrote: On Mon, Apr 23, 2018 at 8:35 PM, Toon Moene wrote: On 04/23/2018 01:00 PM, Richard Biener wrote: Note that while it looks "obvious" in the above source fragment the IL that is presented to optimizers may make things a lot less "low-hanging". Well, the loops are generated by the front end, so I *assume* they are basically the same ... The issue will be boiler-plate code like duplicated loop header checks. That said, it's perfectly understandable that other Fortran compilers have high-level loop opts deeply embedded within their frontends... I agree that this would be more easily handled in the Fortran front end. However, for that it would first have to get a (high level) basic block finder, because it has to be established that consecutive array expressions are part of the same basic block. I discussed high (i.e., Fortran-) level basic blocks briefly in my 2007 GCC Summit talk (http://moene.org/~toon/GCCSummit-2007.pdf, paragraph 7), but I do not think anyone really worked on it. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
