* My 2nd attempt to devel for gcc @ 2021-03-27 23:37 pawel k. 2021-03-28 0:26 ` Jonathan Wakely 2021-03-29 17:25 ` Joseph Myers 0 siblings, 2 replies; 10+ messages in thread From: pawel k. @ 2021-03-27 23:37 UTC (permalink / raw) To: gcc Hello, I would like to ask whether there would be interest in the project to be able to build a single binary of gcc where target would be selectable with option flags ie more than one target could be included and aimed for by single binary. If so i could try myself at adding such feature to gcc. It looks ambitious but doable. If so, my another question would be whether no matter configure flags, when for example x86 is selected as target, genned target code is always same. Best regards, Pawel Kunio ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-27 23:37 My 2nd attempt to devel for gcc pawel k. @ 2021-03-28 0:26 ` Jonathan Wakely 2021-03-28 1:20 ` pawel k. 2021-03-29 17:25 ` Joseph Myers 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2021-03-28 0:26 UTC (permalink / raw) To: pawel.kunio; +Cc: gcc On Sat, 27 Mar 2021, 23:38 pawel k. via Gcc, <gcc@gcc.gnu.org> wrote: > Hello, > I would like to ask whether there would be interest in the project to be > able to build a single binary of gcc where target would be selectable with > option flags ie more than one target could be included and aimed for by > single binary. > > If so i could try myself at adding such feature to gcc. It looks ambitious > but doable. > See the reply from Jakub. > If so, my another question would be whether no matter configure flags, when > for example x86 is selected as target, genned target code is always same. > No, some configure options can affect it, e.g. --with-arch ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-28 0:26 ` Jonathan Wakely @ 2021-03-28 1:20 ` pawel k. 2021-03-28 9:34 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: pawel k. @ 2021-03-28 1:20 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc Hmm, Thanks. Not sure I can see answer from him. Ill recheck it. Best regards, Pawel Kunio niedz., 28.03.2021, 01:27 użytkownik Jonathan Wakely <jwakely.gcc@gmail.com> napisał: > > > On Sat, 27 Mar 2021, 23:38 pawel k. via Gcc, <gcc@gcc.gnu.org> wrote: > >> Hello, >> I would like to ask whether there would be interest in the project to be >> able to build a single binary of gcc where target would be selectable with >> option flags ie more than one target could be included and aimed for by >> single binary. >> >> If so i could try myself at adding such feature to gcc. It looks ambitious >> but doable. >> > > > See the reply from Jakub. > > > >> If so, my another question would be whether no matter configure flags, >> when >> for example x86 is selected as target, genned target code is always same. >> > > > No, some configure options can affect it, e.g. --with-arch > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-28 1:20 ` pawel k. @ 2021-03-28 9:34 ` Jonathan Wakely 2021-03-28 9:53 ` pawel k. 2021-03-28 11:54 ` pawel k. 0 siblings, 2 replies; 10+ messages in thread From: Jonathan Wakely @ 2021-03-28 9:34 UTC (permalink / raw) To: pawel.kunio; +Cc: gcc On Sun, 28 Mar 2021, 02:20 pawel k., <pawel.kunio@gmail.com> wrote: > Hmm, > Thanks. Not sure I can see answer from him. Ill recheck it. > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-28 9:34 ` Jonathan Wakely @ 2021-03-28 9:53 ` pawel k. 2021-03-28 11:54 ` pawel k. 1 sibling, 0 replies; 10+ messages in thread From: pawel k. @ 2021-03-28 9:53 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc Hello, Yea ok got it. Ill reply. I dont get email notifications from him. Ill prepare reply asap as of what we can or cannot do and what will be costs and benefits. Then he/you can decide. Best regards, Pawel niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely <jwakely.gcc@gmail.com> napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., <pawel.kunio@gmail.com> wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-28 9:34 ` Jonathan Wakely 2021-03-28 9:53 ` pawel k. @ 2021-03-28 11:54 ` pawel k. 1 sibling, 0 replies; 10+ messages in thread From: pawel k. @ 2021-03-28 11:54 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc Hello, Ok fair enough. I thought cleaner separation of FE and generics interface would be useful feature. It would make adding new FE easier too hopefully. We could provide either multiple FEs per binary or not. Additionally, In single FE per binary option of my fegens cleanup scenario we could avoid calling langhooks via pointer and funcs could be statically called. As on data member read from langhooks needing mem access now, we could avoid this too and const data members would be inlined similarly to macro consts generally. But if there is no demand for fe<->generics cleanup its ok. As on your question on avoiding storing bytecode into lto and rereading it, it indeed looks like bit over the top task for me at the moment. I woukd need to researching it more deeply. What i rather meant was compiling in multiple targets and choosing via cmdline opts which one to use. As on Your questions wrt multiple targets, indeed target specific constint macro unrolling would need generally a call and additionally probably indirect one unfirtunately. If the hit on perfirmance is too big here its probably a no go. Unless we just cleanup generics target interface, then target data member reads can be as cheap as constint macro unrolling. As on command line processing, we would probably unfortunately have to make it multipass and opts unresolved in first pass would get checked against registered target opts available in 2nd pass only after targetsel option is found. Id check for availability of all required fkags in last phase where here selected target is already known. Additionally this multitarget scenario might have intermediate "generics target interface cleanup phase" which would help cleaning up this lower interface at first, posibly simplifying target autogen and unifying between constdata reads and calls to a target etc. In this phase data member reads from target will be as cheap as const int macro unrolling too. Here we can also think whether to stop at this phase or to extend it into multitarget feature. Hope all this makes my rationale bit less chaotic. If theres demand on researching and hopefully implementing any of these, please let me know. Best regards, Pawel Kunio niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely <jwakely.gcc@gmail.com> napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., <pawel.kunio@gmail.com> wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-27 23:37 My 2nd attempt to devel for gcc pawel k. 2021-03-28 0:26 ` Jonathan Wakely @ 2021-03-29 17:25 ` Joseph Myers 2021-04-14 5:43 ` pawel k. 1 sibling, 1 reply; 10+ messages in thread From: Joseph Myers @ 2021-03-29 17:25 UTC (permalink / raw) To: pawel.kunio; +Cc: gcc On Sun, 28 Mar 2021, pawel k. via Gcc wrote: > Hello, > I would like to ask whether there would be interest in the project to be > able to build a single binary of gcc where target would be selectable with > option flags ie more than one target could be included and aimed for by > single binary. > > If so i could try myself at adding such feature to gcc. It looks ambitious > but doable. I've estimated this as taking about two person-years of work (that is, two person-years of work for someone with extensive experience in GCC development). https://gcc.gnu.org/legacy-ml/gcc-patches/2010-06/msg02675.html While there have, for example, been various conversions of target macros to hooks, and other such similar changes, since then, I don't think anything fundamentally changes the basic estimate. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-03-29 17:25 ` Joseph Myers @ 2021-04-14 5:43 ` pawel k. 2021-04-14 17:24 ` Joseph Myers 0 siblings, 1 reply; 10+ messages in thread From: pawel k. @ 2021-04-14 5:43 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc Hello, Sorry for slight delay. Very happy if i could prepare prototype of this solution. My best guess is if we could hookify all target code everything callable either from frontends or midend, we could try to severly cut this estimate. I also went back to thread you memtioned, i underestimated time for making gcc driver multitarget and likewise for collect binary. What also puzzles me is work on multilib, i still understand multilib clearly enough. In my previous rant i focused mostly on compiler main exec and making it multitarget. We should if this project makes any or some sense think of how configure flags influence codegen of target sources. Im not 100% sure here. If running such project, id focus first on hookifying and possibly wrapping in functions all target genned and callable code. Then id try to make gcc driver multitarget, then same for collect then same for multilib and in the end for gcc main frontend-specific exec ie interface between midend and target and switching configure to gen all code for all targets selected. If still interested and if i should go to clarifying and researching making driver collect multilib multitarget, please let me know. Also if what i say doesnt make much sense, please also let me know. Best regards, Pawel kunio pon., 29.03.2021, 19:25 użytkownik Joseph Myers <joseph@codesourcery.com> napisał: > On Sun, 28 Mar 2021, pawel k. via Gcc wrote: > > > Hello, > > I would like to ask whether there would be interest in the project to be > > able to build a single binary of gcc where target would be selectable > with > > option flags ie more than one target could be included and aimed for by > > single binary. > > > > If so i could try myself at adding such feature to gcc. It looks > ambitious > > but doable. > > I've estimated this as taking about two person-years of work (that is, two > person-years of work for someone with extensive experience in GCC > development). > > https://gcc.gnu.org/legacy-ml/gcc-patches/2010-06/msg02675.html > > While there have, for example, been various conversions of target macros > to hooks, and other such similar changes, since then, I don't think > anything fundamentally changes the basic estimate. > > -- > Joseph S. Myers > joseph@codesourcery.com > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-04-14 5:43 ` pawel k. @ 2021-04-14 17:24 ` Joseph Myers 2021-04-14 17:31 ` Prathamesh Kulkarni 0 siblings, 1 reply; 10+ messages in thread From: Joseph Myers @ 2021-04-14 17:24 UTC (permalink / raw) To: pawel.kunio; +Cc: gcc On Wed, 14 Apr 2021, pawel k. via Gcc wrote: > My best guess is if we could hookify all target code everything callable > either from frontends or midend, we could try to severly cut this estimate. That's a 700-patch series (there are about 700 target macros). For every target macro, it's necessary to work out the corresponding target hook interface, which shouldn't always correspond one-to-one to the macro interface (and hooks have well-defined argument types, which macros don't always), and deal with the conversion, covering all the irregular ways in which different targets define the macros (including e.g. cases where some architectures define a target macro differently for different target OSes). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: My 2nd attempt to devel for gcc 2021-04-14 17:24 ` Joseph Myers @ 2021-04-14 17:31 ` Prathamesh Kulkarni 0 siblings, 0 replies; 10+ messages in thread From: Prathamesh Kulkarni @ 2021-04-14 17:31 UTC (permalink / raw) To: Joseph Myers; +Cc: pawel.kunio, GCC Development On Wed, 14 Apr 2021 at 22:54, Joseph Myers <joseph@codesourcery.com> wrote: > > On Wed, 14 Apr 2021, pawel k. via Gcc wrote: > > > My best guess is if we could hookify all target code everything callable > > either from frontends or midend, we could try to severly cut this estimate. > > That's a 700-patch series (there are about 700 target macros). For every > target macro, it's necessary to work out the corresponding target hook > interface, which shouldn't always correspond one-to-one to the macro > interface (and hooks have well-defined argument types, which macros don't > always), and deal with the conversion, covering all the irregular ways in > which different targets define the macros (including e.g. cases where some > architectures define a target macro differently for different target > OSes). Joseph has articulately summarized the process in this thread on target macro conversion: https://gcc.gnu.org/pipermail/gcc/2015-February/216586.html Thanks, Prathamesh > > -- > Joseph S. Myers > joseph@codesourcery.com ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-04-14 17:31 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-27 23:37 My 2nd attempt to devel for gcc pawel k. 2021-03-28 0:26 ` Jonathan Wakely 2021-03-28 1:20 ` pawel k. 2021-03-28 9:34 ` Jonathan Wakely 2021-03-28 9:53 ` pawel k. 2021-03-28 11:54 ` pawel k. 2021-03-29 17:25 ` Joseph Myers 2021-04-14 5:43 ` pawel k. 2021-04-14 17:24 ` Joseph Myers 2021-04-14 17:31 ` Prathamesh Kulkarni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).