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: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Jan 27, 2022)
Hi all, I won't be able to attend, as the IOMMU TG is convening in the same timeslot tomorrow. However, please be advised that (to my knowledge and after checking with Stephano) the Zcea is on-hold and not frozen. Thanks, Philipp. On Wed, 26 Jan 2022 at 14:05, wrote: > Hi all, > > There is an agenda for tomorrow's meeting. If you have topics to > discuss or share, please let me know and I can add them to the agenda. > > Agenda: > > > - Bump GCC default ISA spec and got bug report[1] for that. > > > - RISC-V subextension related implement progress > > - Scalar Crypto develop plan > > - Zmmul spec has forzen and toolchain implement of it > > - Zcea 'tablejump' instruction implement > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 > > Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. > > Topic: RISC-V GNU Toolchain Biweekly Sync-up > > Join Zoom Meeting > https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 > > Meeting ID: 893 9360 0951 > Passcode: 899662 > > BEIJING, China > 11:00pThu, Jan 27 2022 > > 12:00aFri, Jan 27 2022 > > PST/PDT, Pacific Standard Time (US) > 7:00aThu, Jan 27 2022 > 8:00aThu, Jan 27 2022 > > PHILADELPHIA, United States, Pennsylvania > 10:00aThu, Jan 27 2022 > 11:00aThu, Jan 27 2022 > >
Re: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aripl 07, 2022)
Please note that the Zc* extension family did not make it to ratification last year. To my knowledge, the specification contents are not frozen and still subject to change. Thanks, Philipp. On Wed, 6 Apr 2022 at 14:11, wrote: > Hi all, > > Here is the agenda for tomorrow's meeting. If you have topics to > discuss or share, please let me know and I can add them to the agenda. > > Agenda: > > > - "-latomic" and "-pthread" problem discuss in RISC-V [1] > > > - RVV gcc implement progress [2] > > > - RISC-V subextension related implement progress > > - Zc* extension supports status > > - CMO extension supports status > > - ZTSO supports status > > > - Open topics > > > [1] https://github.com/riscv-collab/riscv-gcc/issues/337 > > [2] https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next > >https://github.com/riscv-collab/riscv-gcc/issues/335 > > > > Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. > > > Topic: RISC-V GNU Toolchain Biweekly Sync-up > Time: Mar 10, 2022 11:00 PM Singapore > Every 2 weeks on Thu, until Jun 30, 2022, 9 occurrence(s) > > > Please download and import the following iCalendar (.ics) files to your > calendar system. > > Weekly: > > > https://zoom.us/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m > > > Join Zoom Meeting > https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 > > > Meeting ID: 893 9360 0951 > Passcode: 899662 > > > BEIJING, China > 10:00pThu, Aripl 07 2022 > > 11:00aFri, Aripl 07 2022 > > PST/PDT, Pacific Standard Time (US) > 7:00aThu, Aripl 07 2022 > 8:00aThu, Aripl 07 2022 > > PHILADELPHIA, United States, Pennsylvania > 10:00aThu, Aripl 07 2022 > 11:00aThu, Aripl 07 2022 > > > Paris, France > 16:00pThu, Aripl 07 2022 > 17:00pThu, Aripl 07 2022 >
[AArch64] Storing a copy of all function arguments on the stack for debug/instrumentation?
To aid in debugging and instrumentation (we would like to look at a stopped program and unwind while recording all argument values), I would like to either store a copy of all register arguments on the caller's stack or record them in the callee's stack on function entry. Both options are straightforward to implement, but I'd like to avoid duplicating work. Has anyone been working on something like this? Thanks, Philipp.
