Re: SH Port Status
Hi All,
Le 21/04/2020 à 17:18, Joel Sherrill a écrit :
> On Tue, Apr 21, 2020 at 4:04 AM Richard Biener
> wrote:
>
>> On Mon, Apr 20, 2020 at 11:05 PM Jeff Law via Gcc wrote:
>>>
>>> On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote:
> On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
>> Hi
>>
>> Over at RTEMS, we were discussing ports to deprecate/obsolete
>> and the SH seems to be on everyone's candidate list. I can't seem
>> to find any gcc test results sh-unknown-elf since 2009 and none
>> for sh-rtems. I know I posted some but when, I can't say. But the
>> new mailing list setup may be messing that up. I expected more
>> recent results.
>>
>> (1) Is my search right? Have there been no test results in 10
>> years?
>>
>> (2) Is the toolchain in jeopardy?
>>
>> (3) I know there was an effort to do an open implementation with
>> j-core.org but there is no News or download item newer than 2016.
>> Is this architecture effectively dead except for legacy hardware
>> out
>> in the field (Sega?)
>>
>> I'm leaning to RTEMS dropping support for the SH after we branch
>> a release and wondering if the GCC community knows anything that
>> I don't.
> I'm not aware of the SH toolchain being in any jeopardy.
>
>
> I'm doing weekly bootstrap (yes, really) & regression tests for
>> {sh4,sh4eb}-
> linux-gnu and daily builds of {sh3,sh3b}-linux-gnu. See
>
> http://gcc.gnu.org/jenkins
Awesome!
>
> The Linux kernel is currently broken, but I suspect it's a transient
>> issue as
> it
> was fine until a week ago -- my tester usually builds the kernel
>> too, but
> that's
> been temporarily disabled for SH targets.
Thanks Jeff! Are you using the simulator in gdb? That's what we have a
>> BSP for?
>>> I'm using qemu -- it's user mode emulation is strong enough that I can
>> create a
>>> little sh4 native root filesystem and bootstrap GCC within it.
>>>
>>>
We build the cross RTEMS tools regularly on Linux, Mac, FreeBSD,
>> Mingw, and
Cygwin. All of our BSPs build including sh1 and the odd sh2e.
Our BSP status for the gdb simulator is unknown. We replaced a lot of
>> testing
infrastructure scripting and the SH hasn't gotten to the top of the
>> list.
>>> ACK. In general, if there's a qemu solution, that's my preference these
>> days.
>>> For the *-elf targets I usually have to fall back to the old gdb-sim
>> bits.
>>>
So we both are building a lot and making sure rot hasn't set in. But in
practice, is this worth the trouble anymore?
>>> I'm not sure about that ;-) I haven't seen anyone suggest removal of
>> the port or
>>> anything like that. The port doesn't use CC0, so there's essentially
>> zero chance
>>> it'll be deprecated for gcc-11. I believe the port is not using LRA, so
>> if/when
>>> we move on deprecating reload, SH might be at some degree of risk.
>>
>> There's two listed maintainers as well (albeit at their anonymous
>> gcc.gnu.org domain).
>>
>
> Thanks to everyone. This has been an interesting discussion. I am
> concluding that
> the SH look pretty healthy especially considering it is a secondary port
> without
> hardware in production
>
> + Linux
> - kernel.org git still has the architecture with multiple boards
> - Debian SuperH mailing list has some recent (light) activity
>
> + RTEMS
>- Tools and all BSPs regularly built for SH1 - SH4 (gcc 9 and 10)
>- We have no hardware to test on. Rely on gdb sim. Haven't tested
> recently
>
> + GCC Testing
>- SH Linux User space is regularly tested on Qemu
>- I did not find recent sh-elf test reports
>- I did build sh-elf from master of gcc, binutils, newlib and can report
> it works well enough to run hello world.
>
> + GCC Maintainer activity
>- maintainer Oleg Endo last committed an SH patch in October 2019
>- maintainer Alexandre Oliva last committed an SH patch in Dec 2017
>
> + GCC Port activity
>- Handful of patches since 1 Oct 2019. Most are actually to fix bugs
> that are SH specific and have ticket numbers.
>
> Overall, I've seen ports in a lot worse shape. :)
>
> Thanks to everyone for the help. I don't know whether RTEMS will keep
> the SH port after our release but the tools shape won't be a factor.
I would like to add the Buildroot project where sh4 targets are still available
[1].
Buildroot provide two defconfig to build a rootfs to be used with Qemu
(qemu_sh4_r2d_defconfig and qemu_sh4eb_r2d_defconfig).
Those defconfig are runtime tested in gitlab-ci [2] (we only do a boot test).
The sh4 toolchain is used in Buildroot's autobuilders [3] to detect build issues
related to sh4 port.
There is also the toolchain-builder [4] project from Bootlin that provide sh4
prebuilt toolchains.
So, the sh4 toolchain and kerne
GCC optimizations with O3
Hello, Does anyone know if the following text from the GCC internals [0] is outdated? -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the following optimization flags: -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-paths -ftree-loop-distribute-patterns -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model -fversion-loops-for-strides I ask because I have an optimization pass that interacts poorly with -O3, but compiles and runs correctly with -O2. I'm trying to find which individual (or combination of optimizations) is triggering the runtime error I'm debugging. I tried running -O2 and manually enable all the optimizations turned on by -O3 (but without specifying -O3) and my pass runs successfully. So, either: * -O3 does more than just enable these optimizations, or * This documentation is outdated and there's something missing. Does someone have an answer? (And if possible point to some code locations so that I can learn where it is.) Thanks! [0] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Re: GCC optimizations with O3
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and -Os.
*/
common/config/arc/arc-common.c:#define OPT_LEVELS_3_PLUS_SPEED_ONLY
OPT_LEVELS_3_PLUS
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_msize_level_, NULL, 0 },
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_malign_call, NULL, 1 },
common/config/nios2/nios2-common.c:{ OPT_LEVELS_3_PLUS, OPT_mfast_sw_div,
NULL, 1 },
opts.c:case OPT_LEVELS_3_PLUS:
opts.c:case OPT_LEVELS_3_PLUS_AND_SIZE:
opts.c:{ OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_unroll_and_jam, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpeel_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribution, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
VECT_COST_MODEL_DYNAMIC },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fversion_loops_for_strides, NULL, 1 },
> On 22.04.2020, at 16:01, Erick Ochoa
> wrote:
>
> Hello,
>
> Does anyone know if the following text from the GCC internals [0] is outdated?
>
> -O3
>
>Optimize yet more. -O3 turns on all optimizations specified by -O2 and
> also turns on the following optimization flags:
>
>-fgcse-after-reload
>-fipa-cp-clone
>-floop-interchange
>-floop-unroll-and-jam
>-fpeel-loops
>-fpredictive-commoning
>-fsplit-paths
>-ftree-loop-distribute-patterns
>-ftree-loop-distribution
>-ftree-loop-vectorize
>-ftree-partial-pre
>-ftree-slp-vectorize
>-funswitch-loops
>-fvect-cost-model
>-fversion-loops-for-strides
>
> I ask because I have an optimization pass that interacts poorly with -O3, but
> compiles and runs correctly with -O2.
> I'm trying to find which individual (or combination of optimizations) is
> triggering the runtime error I'm debugging.
> I tried running -O2 and manually enable all the optimizations turned on by
> -O3 (but without specifying -O3) and my pass runs successfully.
>
> So, either:
> * -O3 does more than just enable these optimizations, or
> * This documentation is outdated and there's something missing.
>
> Does someone have an answer? (And if possible point to some code locations so
> that I can learn where it is.) Thanks!
>
> [0] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Re: GCC optimizations with O3
Thanks! I was looking for "optimize" (since that's the flag defined in
common.opt). But you can probably guess how many lines will match
"optimize".
On 22/04/2020 16:17, Philipp Tomsich wrote:
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and -Os.
*/
common/config/arc/arc-common.c:#define OPT_LEVELS_3_PLUS_SPEED_ONLY
OPT_LEVELS_3_PLUS
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_msize_level_, NULL, 0 },
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_malign_call, NULL, 1 },
common/config/nios2/nios2-common.c:{ OPT_LEVELS_3_PLUS, OPT_mfast_sw_div,
NULL, 1 },
opts.c:case OPT_LEVELS_3_PLUS:
opts.c:case OPT_LEVELS_3_PLUS_AND_SIZE:
opts.c:{ OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_unroll_and_jam, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpeel_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribution, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
VECT_COST_MODEL_DYNAMIC },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fversion_loops_for_strides, NULL, 1 },
On 22.04.2020, at 16:01, Erick Ochoa wrote:
Hello,
Does anyone know if the following text from the GCC internals [0] is outdated?
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also
turns on the following optimization flags:
-fgcse-after-reload
-fipa-cp-clone
-floop-interchange
-floop-unroll-and-jam
-fpeel-loops
-fpredictive-commoning
-fsplit-paths
-ftree-loop-distribute-patterns
-ftree-loop-distribution
-ftree-loop-vectorize
-ftree-partial-pre
-ftree-slp-vectorize
-funswitch-loops
-fvect-cost-model
-fversion-loops-for-strides
I ask because I have an optimization pass that interacts poorly with -O3, but
compiles and runs correctly with -O2.
I'm trying to find which individual (or combination of optimizations) is
triggering the runtime error I'm debugging.
I tried running -O2 and manually enable all the optimizations turned on by -O3
(but without specifying -O3) and my pass runs successfully.
So, either:
* -O3 does more than just enable these optimizations, or
* This documentation is outdated and there's something missing.
Does someone have an answer? (And if possible point to some code locations so
that I can learn where it is.) Thanks!
[0] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Re: GCC optimizations with O3
On 4/22/20 4:01 PM, Erick Ochoa wrote: Hello, Does anyone know if the following text from the GCC internals [0] is outdated? -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the following optimization flags: -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-paths -ftree-loop-distribute-patterns -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model -fversion-loops-for-strides I ask because I have an optimization pass that interacts poorly with -O3, but compiles and runs correctly with -O2. I'm trying to find which individual (or combination of optimizations) is triggering the runtime error I'm debugging. I tried running -O2 and manually enable all the optimizations turned on by -O3 (but without specifying -O3) and my pass runs successfully. Note that using -O2 and enabling all options individually is not equal to -O3. There are some global decisions done based on optimization level. For a difference, you can do: $ gcc --help=optimize -Q -O2 > /tmp/O2 $ gcc --help=optimize -Q -O3 > /tmp/O3 $ diff -U 0 /tmp/O2 /tmp/O3 --- /tmp/O2 2020-04-22 16:19:54.123495072 +0200 +++ /tmp/O3 2020-04-22 16:19:56.903467468 +0200 @@ -54 +54 @@ - -fgcse-after-reload [disabled] + -fgcse-after-reload [enabled] @@ -73 +73 @@ - -fipa-cp-clone [disabled] + -fipa-cp-clone [enabled] @@ -103 +103 @@ - -floop-interchange [disabled] + -floop-interchange [enabled] @@ -106 +106 @@ - -floop-unroll-and-jam[disabled] + -floop-unroll-and-jam[enabled] @@ -122 +122 @@ - -fpeel-loops [disabled] + -fpeel-loops [enabled] @@ -126 +126 @@ - -fpredictive-commoning [disabled] + -fpredictive-commoning [enabled] @@ -178,2 +178,2 @@ - -fsplit-loops[disabled] - -fsplit-paths[disabled] + -fsplit-loops[enabled] + -fsplit-paths[enabled] @@ -215 +215 @@ - -ftree-loop-distribution [disabled] + -ftree-loop-distribution [enabled] @@ -220 +220 @@ - -ftree-loop-vectorize[disabled] + -ftree-loop-vectorize[enabled] @@ -223 +223 @@ - -ftree-partial-pre [disabled] + -ftree-partial-pre [enabled] @@ -230 +230 @@ - -ftree-slp-vectorize [disabled] + -ftree-slp-vectorize [enabled] @@ -242 +242 @@ - -funswitch-loops [disabled] + -funswitch-loops [enabled] @@ -249,2 +249,2 @@ - -fvect-cost-model=[unlimited|dynamic|cheap] cheap - -fversion-loops-for-strides [disabled] + -fvect-cost-model=[unlimited|dynamic|cheap] dynamic + -fversion-loops-for-strides [enabled] Martin So, either: * -O3 does more than just enable these optimizations, or * This documentation is outdated and there's something missing. Does someone have an answer? (And if possible point to some code locations so that I can learn where it is.) Thanks! [0] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Re: GCC optimizations with O3
On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote:
> ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
> common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
> common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and
> -Os. */
> common/config/arc/arc-common.c:#define OPT_LEVELS_3_PLUS_SPEED_ONLY
> OPT_LEVELS_3_PLUS
> common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
> OPT_msize_level_, NULL, 0 },
> common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
> OPT_malign_call, NULL, 1 },
> common/config/nios2/nios2-common.c:{ OPT_LEVELS_3_PLUS, OPT_mfast_sw_div,
> NULL, 1 },
> opts.c:case OPT_LEVELS_3_PLUS:
> opts.c:case OPT_LEVELS_3_PLUS_AND_SIZE:
> opts.c:{ OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_unroll_and_jam, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpeel_loops, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribution, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
> VECT_COST_MODEL_DYNAMIC },
> opts.c:{ OPT_LEVELS_3_PLUS, OPT_fversion_loops_for_strides, NULL, 1 },
That is not everything, some spots also compare the value of optimize, e.g.
tree-ssa-loop-ivcanon.c: ||
optimize >= 3, true);
tree-ssa-loop-ivcanon.c: ret = tree_unroll_loops_completely (optimize >=
3, false);
tree-ssa-loop-niter.c: if (optimize >= 3)
An -O? option is not just a set of suboptions it enables, and there are
other option interactions (e.g. some ftree-* etc. options might be set, but
for whatever reason the corresponding pass isn't enabled, e.g. -Og or -O0
have significantly different parts of pass lists and many passes just aren't
schedule at all in those cases).
Jakub
Re: GCC optimizations with O3
On 22/04/2020 16:25, Jakub Jelinek wrote:
On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote:
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and -Os.
*/
common/config/arc/arc-common.c:#define OPT_LEVELS_3_PLUS_SPEED_ONLY
OPT_LEVELS_3_PLUS
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_msize_level_, NULL, 0 },
common/config/arc/arc-common.c:{ OPT_LEVELS_3_PLUS_SPEED_ONLY,
OPT_malign_call, NULL, 1 },
common/config/nios2/nios2-common.c:{ OPT_LEVELS_3_PLUS, OPT_mfast_sw_div,
NULL, 1 },
opts.c:case OPT_LEVELS_3_PLUS:
opts.c:case OPT_LEVELS_3_PLUS_AND_SIZE:
opts.c:{ OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_floop_unroll_and_jam, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpeel_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribution, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
VECT_COST_MODEL_DYNAMIC },
opts.c:{ OPT_LEVELS_3_PLUS, OPT_fversion_loops_for_strides, NULL, 1 },
That is not everything, some spots also compare the value of optimize, e.g.
tree-ssa-loop-ivcanon.c: ||
optimize >= 3, true);
tree-ssa-loop-ivcanon.c: ret = tree_unroll_loops_completely (optimize >=
3, false);
tree-ssa-loop-niter.c: if (optimize >= 3)
An -O? option is not just a set of suboptions it enables, and there are
other option interactions (e.g. some ftree-* etc. options might be set, but
for whatever reason the corresponding pass isn't enabled, e.g. -Og or -O0
have significantly different parts of pass lists and many passes just aren't
schedule at all in those cases).
Hi Jakub,
in order for me to debug my issue, I'm going to have to refactor passes
which directly reference optimize. I am planning on refactoring them by
creating a "$pass_opt_level". This variable can be set via command line
or somewhere in opts.c. I can then substitute the references to optimize
with $pass_opt_level.
Would this be worthy of contribution?
Jakub
Re: GCC optimizations with O3
Hello, On Wed, 22 Apr 2020, Erick Ochoa wrote: > in order for me to debug my issue, I'm going to have to refactor passes > which directly reference optimize. For debugging you can also work backwards: use -O3 and add -fno-xy options. At least you then know (after disabling all O3 passes) that it's one of those places that explicitely are tacked off the opt level. > I am planning on refactoring them by creating a "$pass_opt_level". This > variable can be set via command line or somewhere in opts.c. I can then > substitute the references to optimize with $pass_opt_level. I think for local decisions in passes that currenly use 'optimize' the better strategy is to determine the underlying cause for having that test, and add a flag for that (or reuse an existing one, e.g. if the reason was "don't disturb debugging experience" then create or use a flag specific to that role). For the global decisions mentioned by Jakub: that's by nature not specific to a pass, hence a per-pass opt level wouldn't help. Ciao, Michael.
AVR CC0 transition
Hi, I'm thinking about attempting to do the CC0 transition for the AVR port in my spare time. I've read the CC0Transition gcc wiki page, and as the AVR ISA does not have non-condition-code clobbering arithmetic instructions, concluded that I'd have to follow the steps outlined for case #2. Are there any other things I need to watch out for? Regards Senthil
Re: AVR CC0 transition
On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: > Hi, > > I'm thinking about attempting to do the CC0 transition for the > AVR port in my spare time. I've read the CC0Transition gcc wiki > page, and as the AVR ISA does not have non-condition-code > clobbering arithmetic instructions, concluded that I'd have to > follow the steps outlined for case #2. > > Are there any other things I need to watch out for? Not offhand. You might want to look at how Bernd did the m68k though. I think a conceptually similar transition would be reasonable for AVR as well as the alternative would be dropping the AVR port. Jeff
Re: AVR CC0 transition
Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: [..] as the alternative would be dropping the AVR port. Shouldn't that work be sponsored by Microchip (or whoever currently owns AVR)? Arduino Inc. might also be highly interested in continued AVR-support. Cheers Morty -- Redheads Ltd. Softwaredienstleistungen Schillerstr. 14 90409 Nürnberg Telefon: +49 (0)911 180778-50 E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de Geschäftsführer: Andreas Hanke Sitz der Gesellschaft: Lauf Amtsgericht Nürnberg HRB 22681 Ust-ID: DE 249436843
Re: AVR CC0 transition
On Wed, 2020-04-22 at 19:52 +0200, Moritz Strübe wrote: > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: > > [..] as the > > alternative would be dropping the AVR port. > > Shouldn't that work be sponsored by Microchip (or whoever currently owns > AVR)? Arduino Inc. might also be highly interested in continued > AVR-support. It'd be useful. GCC is a volunteer project, so nothing is preventing them from getting directly involved with the transition by hiring/sponsoring someone to do it and/or generally maintain/improve the AVR port, nor does anything stand in their way of participating indirectly via the bug bounty program that's been started for the AVR transition. Jeff
Re: AVR CC0 transition
On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe wrote: > > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: > > [..] as the > > alternative would be dropping the AVR port. > > Shouldn't that work be sponsored by Microchip (or whoever currently owns > AVR)? Arduino Inc. might also be highly interested in continued > AVR-support. > One would like to think that. They haven't released an updated GNU toolchain since 2016 per this website: https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers Has there been a company sponsored community visible maintainer since Eric Weddington left the company in the 2013 time frame? I'm happy to be wrong on any of that. :) --joel RTEMS > > Cheers > Morty > > -- > Redheads Ltd. Softwaredienstleistungen > Schillerstr. 14 > 90409 Nürnberg > > Telefon: +49 (0)911 180778-50 > E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de > > Geschäftsführer: Andreas Hanke > Sitz der Gesellschaft: Lauf > Amtsgericht Nürnberg HRB 22681 > Ust-ID: DE 249436843 > >
לרגל המצב משרד האוצר העמיד 8 מיליארד להלוואות בערבות מדינה, לעסקים בדוק זכאותך
לרג המצב משרד האוצר העמיד 8 מיליארד לטובת עסקים נפגעי הקורונה אופציה לגרייס לחצי שנה עד חצי מיליון שח .אנו נבדוק עבורך בדיקה כפולה קרן קורונה+קרן ערבות מדינה לבדיקת זכאותך תנאי סף ללא חזרות המחאות מהחשבון בשנה האחרונה מחזור חודשי מעל 30,000 שח לחץ כאן שולח: מטה העצמאים והחברות. כתובת השולח: תד 10300987, תל אביב. הסר (unsubscribe) אותי מרשימת התפוצה אם דיוור זה חשוד בעינייך כספאם, אנא ידע אותנו . נשלח באמצעות מערכת דיוור אלקטרוני שלח מסר מבית קומסטאר
scalar_storage_order question
Hi all (and Eric),
I have a question about scalar_storage_order and support of type
punning between types that have different byte order.
Take:
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
#define __big_endian__ scalar_storage_order("big-endian")
#define __little_endian__ scalar_storage_order("little-endian")
typedef union {
uint32_t val;
uint8_t v[4];
} __attribute__((__big_endian__)) upal_u32be_t;
typedef union {
uint32_t val;
uint8_t v[4];
} __attribute__((__little_endian__)) upal_u32le_t;
static inline uint32_t native_to_big_endian(uint32_t t)
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
return t;
#else
return __builtin_bswap32(t);
#endif
}
static inline uint32_t native_to_little_endian(uint32_t t)
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
return __builtin_bswap32(t);
#else
return t;
#endif
}
void link_error(void);
#ifndef __OPTIMIZE__
void link_error(void)
{
__builtin_abort ();
}
#endif
#define test(p, p1, i) do { if (p[i] != p1[i]) link_error (); } while (0)
#define tests(p, p1) do { test(p, p1, 0); test(p, p1, 1); \
test(p, p1, 2); test(p, p1, 3); } while (0)
int main(void)
{
uint8_t *p, *p1;
uint32_t u = 0x12345678;
uint32_t bu = ((upal_u32be_t*)&u)->val;
uint32_t b1u = native_to_big_endian(u);
p = (uint8_t*)&bu;
p1 = (uint8_t*)&b1u;
tests(p, p1);
u = 0x12345678;
uint32_t lu = ((upal_u32le_t*)&u)->val;
uint32_t l1u = native_to_little_endian(u);
p = (uint8_t*)&lu;
p1 = (uint8_t*)&l1u;
tests(p, p1);
return 0;
}
CUT ---
Should this be allowed/working everywhere (I mean without considering
PDP byte order)?
Right now this works at -O0, we don't abort but at -O1 and above FRE
and CCP both misbehave in doing a constant prop of 0x12345678 through
the upal_u32le_t/upal_u32be_t access.
I notice this statement in the documentation:
Moreover, the use of type punning or aliasing to toggle the storage
order is not supported; that is to say, a given scalar object cannot
be accessed through distinct types that assign a different storage
order to it.
--- CUT ---
But I am not 100% sure that is the case here but I hope I am wrong in
saying this is not supported.
Thanks,
Andrew
Re: scalar_storage_order question
> I notice this statement in the documentation: > Moreover, the use of type punning or aliasing to toggle the storage > order is not supported; that is to say, a given scalar object cannot > be accessed through distinct types that assign a different storage > order to it. > --- CUT --- > But I am not 100% sure that is the case here but I hope I am wrong in > saying this is not supported. This seems to me a fairly standard example of type punning: uint32_t u = 0x12345678; uint32_t bu = ((upal_u32be_t*)&u)->val; u = 0x12345678; uint32_t lu = ((upal_u32le_t*)&u)->val; u is accessed through upal_u32be_t and upal_u32le_t, i.e. BE and LE. -- Eric Botcazou
Re: scalar_storage_order question
On Wed, Apr 22, 2020 at 1:14 PM Eric Botcazou wrote: > > > I notice this statement in the documentation: > > Moreover, the use of type punning or aliasing to toggle the storage > > order is not supported; that is to say, a given scalar object cannot > > be accessed through distinct types that assign a different storage > > order to it. > > --- CUT --- > > But I am not 100% sure that is the case here but I hope I am wrong in > > saying this is not supported. > > This seems to me a fairly standard example of type punning: > > uint32_t u = 0x12345678; > uint32_t bu = ((upal_u32be_t*)&u)->val; > > u = 0x12345678; > uint32_t lu = ((upal_u32le_t*)&u)->val; > > u is accessed through upal_u32be_t and upal_u32le_t, i.e. BE and LE. What if we had this: uint32_t u = 0x12345678; upal_u32be_t tempb; memcpy (&tempb, &u, sizeof(uint32_t)); uint32_t bu = tempb.val; Is that valid? We still run into the wrong code with the above case. memcpy here should be considered a byte-by-byte copy and therefor should not have any type punning except for to bytes. Thanks, Andrew Pinski > > -- > Eric Botcazou
RE: Not usable email content encoding
> -Original Message- > From: Gcc On Behalf Of Florian Weimer > Sent: Thursday, March 19, 2020 1:59 PM > To: Richard Biener > Cc: overse...@gcc.gnu.org; Jonathan Wakely via Gcc ; > Overseers mailing list ; Segher Boessenkool > ; Alexander Monakov ; > Frank Ch. Eigler ; Frank Ch. Eigler ; > Tom Tromey > Subject: Re: Not usable email content encoding > > * Richard Biener: > > > On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer > wrote: > >> > >> * Tom Tromey: > >> > >> > Also, gerrit was pretty bad about threading messages, so it became > >> > quite hard to follow progress in email (but following all patches > >> > in the web interface is very difficult, a problem shared by all these web > UIs). > >> > >> What I found most disappointing was that the web interface doesn't > >> guide you to the next reasonable step for your reviews and patches, > >> like showing comments which need addressing. Tagging messages in an > >> email client for later action actually works better than that, I think. > > > > I guess if anything we'd want something git-centric now like github or > > gitlab pull requests & reviews. The only complication is approval > > then which would still mean manual steps. > > Gitlab has a “merge if CI passes” button, I think. There are similar > third-party > solutions for Github. A bit late to the party, but this really doesn't work that well because until recent version of gitlab there was no fairness guarantee. another patch could be approved after mine (with hours in between because of CI) and yet still get merged first causing my own patch to no longer apply, you'd rebase and roll the dice again. To fix this they added merge trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ but trains for GCC Will likely be very short because of Changelog conflicts. So I don't think an automated merge workflow would work for projects where every single commit changes the same files. For these workflows to work as well you'd need to have a policy that every single commit go through CI, as a non-green master could flush your entire train if it's rebased on a bad commit. > > > Patch review would also not be publicly visible and archived(?) so > > both chiming in late after visible progress and archeology would be > > harder. > > The comments could be archived on a mailing list. But there is only some > threading. Maybe this can be compensated to some extent by producing > smaller patches, so that there's less reason for mega-review-threads. > > I don't know if Gitlab supports patch reviews, or if you only can review all > the > squashed changes in a merge request. Github and Gerrit support comments > on individual patches, but Pagure does not, so this is not something that has > universal support in all such tools. (I would consider such a feature > critical for > glibc development.) > > I haven't figured out yet under what circumstances Github links commits to > pull requests in the web UI. I'm not sure if this relationship is available > outside the web UI. (Obviously, this is missing from the current gcc-patches > feed as well.)
Re: AVR CC0 transition
On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote: > > On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: > > Hi, > > > > I'm thinking about attempting to do the CC0 transition for the > > AVR port in my spare time. I've read the CC0Transition gcc wiki > > page, and as the AVR ISA does not have non-condition-code > > clobbering arithmetic instructions, concluded that I'd have to > > follow the steps outlined for case #2. > > > > Are there any other things I need to watch out for? > Not offhand. You might want to look at how Bernd did the m68k though. I > think a > conceptually similar transition would be reasonable for AVR as well as the > alternative would be dropping the AVR port. Hi Jeff, Thanks, I will take a look at Bernd's work. IIRC, he took a different approach from what was suggested in the wiki, right? And yes, my personal motivation to work on this is to keep the AVR port alive in upstream gcc. Regards Senthil
Re: AVR CC0 transition
On Wed, Apr 22, 2020 at 11:37 PM Joel Sherrill wrote: > > On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe > wrote: > > > > > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: > > > [..] as the > > > alternative would be dropping the AVR port. > > > > Shouldn't that work be sponsored by Microchip (or whoever currently owns > > AVR)? Arduino Inc. might also be highly interested in continued > > AVR-support. > > > > One would like to think that. They haven't released an updated GNU > toolchain > since 2016 per this website: > > https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers > > > Has there been a company sponsored community visible maintainer since > Eric Weddington left the company in the 2013 time frame? > Well, if write-after-approval access for the avr backend counts, I work for Microchip (Atmel, before it got acquired), and I have proposed and committed a bunch of patches since 2013 :) Regards Senthil
Re: GCC optimizations with O3
On Wed, Apr 22, 2020 at 10:25 AM Jakub Jelinek via Gcc wrote: > An -O? option is not just a set of suboptions it enables Maybe it should be. I notice this come up often enough at least.
Re: Not usable email content encoding
* Tamar Christina: > A bit late to the party, but this really doesn't work that well > because until recent version of gitlab there was no fairness > guarantee. another patch could be approved after mine (with hours > in between because of CI) and yet still get merged first causing my > own patch to no longer apply, you'd rebase and roll the dice again. > To fix this they added merge trains > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > but trains for GCC Will likely be very short because of Changelog > conflicts. So I don't think an automated merge workflow would work > for projects where every single commit changes the same files. I had not thought about that. Does Gitlab support pluggable merge helpers? The gnulib changelog auto-merger did a great job when we were still writing changelogs for glibc.
Re: AVR CC0 transition
> Thanks, I will take a look at Bernd's work. IIRC, he took a > different approach from what was suggested in the wiki, right? Yes, let's say that it's a half-baked conversion, probably a consequence of the bounty. This might be good enough, depending on the architecture. -- Eric Botcazou
Re: scalar_storage_order question
> What if we had this: > uint32_t u = 0x12345678; > upal_u32be_t tempb; > memcpy (&tempb, &u, sizeof(uint32_t)); > uint32_t bu = tempb.val; > > Is that valid? We still run into the wrong code with the above case. > memcpy here should be considered a byte-by-byte copy and therefor > should not have any type punning except for to bytes. The usual trick of people doing type punning and pretending they don't. ;-) No, this cannot work as-is, although it's probably fixable by blocking the propagation through the memcpy in case the scalar order is flipped, unlike the previous example. -- Eric Botcazou
