My 2nd attempt to devel for gcc

My 2nd attempt to devel for gcc

[pawel k.]

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

Re: My 2nd attempt to devel for gcc

[Jonathan Wakely]

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

Re: My 2nd attempt to devel for gcc

[pawel k.]

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
>
>
>

Re: My 2nd attempt to devel for gcc

[Jonathan Wakely]

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

Re: My 2nd attempt to devel for gcc

[pawel k.]

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
>
>
>
>

Re: My 2nd attempt to devel for gcc

[pawel k.]

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
>
>
>
>

Re: My 2nd attempt to devel for gcc

[Joseph Myers]

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

Re: My 2nd attempt to devel for gcc

[pawel k.]

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
>

Re: My 2nd attempt to devel for gcc

[Joseph Myers]

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

Re: My 2nd attempt to devel for gcc

[Prathamesh Kulkarni]

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