Re: Questions about macro fusion pass
Hi Richard, Thank you for the clarification. I was curious because LLVM seems to support scheduling separate fusible instructions together. Thanks :) Hau On Fri, Jan 10, 2025 at 1:30 AM Richard Sandiford wrote: > Hau Hsu via Gcc writes: > > Hi, > > > > I have a question about GCC's macro fusion pass. > > In the GCC internals doc, there is a hook for scheduling: > > TARGET_SCHED_MACRO_FUSION_PAIR_P > > < > https://gcc.gnu.org/onlinedocs/gccint/Scheduling.html#index-TARGET_005fSCHED_005fMACRO_005fFUSION_005fPAIR_005fP > > > > It says: > >> If this hook returns true for the given insn pair (prev and curr), > >> the scheduler will put them into a sched group, and they will not be > > scheduled apart. > > > > My questions are, does this mean that GCC is just adding a mark on > > back-to-back insns (as their name *prev* and *curr* suggests) and won't > > separate them during scheduling? Does GCC try to search for separate but > > fusible insns and to put them together? > > > > I also traced the code in sched_macro_fuse_insns() > > < > https://github.com/gcc-mirror/gcc/blob/640b550425180bdab7bc67edc6a48465f4023888/gcc/sched-deps.cc#L2844-L2880 > >, > > but it seems only grouping back-to-back insns ... > > Yeah, that's right. TARGET_SCHED_MACRO_FUSION_PAIR_P just keeps existing > groups together. TARGET_SCHED_FUSION_PRIORITY provides a way of trying > to form new groups. > > Thanks, > Richard > >
gcc-13-20250110 is now available
Snapshot gcc-13-20250110 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20250110/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 605803cf4089955c39dcbed97b343550581b8eed You'll find: gcc-13-20250110.tar.xz Complete GCC SHA256=67ce8d7229139c8da2b6cb6423dc8d5e03e307977d8ca80ee959d0ef55101e27 SHA1=bea26ae502523b5c83f7518ebbfd29141762782a Diffs from 13-20250103 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 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.
diagnostic framework message array
What should I do with the following message? cobol1: warning: depth line copybook filename - cobol1: warning: 11 prog.cob cobol1: warning: 21 copy1.CPY cobol1: warning: 31 copy2.CPY cobol1: warning: 41 copy3.CPY cobol1: error: copy3.CPY:1: recursive copybook: 'copy1.CPY' includes itself A COBOL copybook is similar to a C include file, but cannot include itself, even indirectly. That's the rule. There's no form of "include guard". (There's good reason. The Compiler Directing Facility (CDF) supports text substitution on the copybook, so that the same input may have names with different prefixes, say, in different programs.) No rule says the compiler must tell the user the route to copybook recursion, but I'll bet it's not controversial. As of now, the warning messages are sent straight to fprintf(3), and only the error goes to emit_diagnostic_valist(). Or will, after I sort out locations within the CDF. --jkl
