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....@gmail.com> napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., <pawel.ku...@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 > > > >
