public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	 Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH 3/N] Come up with casm global state.
Date: Thu, 21 Oct 2021 14:42:10 +0200	[thread overview]
Message-ID: <CAFiYyc2K-VTMBRQTg=F8A3Ee5ph0+7-Pv_aotO8HaAS6MN_42A@mail.gmail.com> (raw)
In-Reply-To: <856ae6d3-d1f7-4f00-0af0-afeb55a46f06@suse.cz>

On Thu, Oct 21, 2021 at 11:47 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 10/5/21 13:54, Richard Biener wrote:
> > On Mon, Oct 4, 2021 at 1:13 PM Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 9/22/21 11:59, Richard Biener wrote:
> >>> On Thu, Sep 16, 2021 at 3:12 PM Martin Liška <mliska@suse.cz> wrote:
> >>>>
> >>>> This patch comes up with asm_out_state and a new global variable casm.
> >>>>
> >>>> Tested on all cross compilers.
> >>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>>>
> >>>> Ready to be installed?
> >>>
> >>>           * output.h (struct asm_out_file): New struct that replaces a
> >>> ^^^
> >>> asm_out_state?
> >>
> >> Yes, sure!
> >>
> >>>
> >>> You replace a lot of asm_out_file - do we still need the macro then?
> >>> (I'd have simplified the patch leaving that replacement out at first)
> >>
> >> Well, I actually replaced only a very small fraction of the usage of asm_out_file.
> >>
> >> $ git grep asm_out_file | grep -v ChangeLog | wc -l
> >>
> >> 1601
> >>
> >>
> >> So I think we should live with the macro for some time ...
> >>
> >>>
> >>> You leave quite some global state out of the struct that is obviously
> >>> related, in the diff I see object_block_htab for example.
> >>
> >> Yes, I'm aware of it. Can we do that incrementally?
> >>
> >>> Basically
> >>> everything initialized in init_varasm_once is a candidate (which
> >>> then shows const_desc_htab and shared_constant_pool as well
> >>> as pending_assemble_externals_set).
> >>
> >> Well, these would probably need a different header file (or another #include ... must
> >> be added before output.h :// ).
> >>
> >>> For the goal of outputting
> >>> early DWARF to another file the state CTOR could have a mode
> >>> to not initialize those parts or we could have asm-out-state-with-sections
> >>> as base of asm-out-state.
> >>
> >> Yes, right now asm_out_state ctor is minimal:
> >>
> >>     asm_out_state (): out_file (NULL), in_section (NULL),
> >>       sec ({}), anchor_labelno (0), in_cold_section_p (false)
> >>     {
> >>       section_htab = hash_table<section_hasher>::create_ggc (31);
> >>     }
> >>
> >>>
> >>> In the end there will be a target part of the state so I think
> >>> construction needs to be defered to the target which can
> >>> derive from asm-out-state and initialize the part it needs.
> >>> That's currently what targetm.asm_out.init_sections () does
> >>> and we'd transform that to a targetm.asm_out.create () or so.
> >>> That might already be necessary for the DWARF stuff.
> >>
> >> So what do you want to with content of init_varasm_once function?
> >
> > It goes away ;)  Or rather becomes the invocation of the
> > asm-out-state CTOR via the target hook.
> >
> >>>
> >>> That said, dealing with the target stuff piecemail is OK, but maybe
> >>> try to make sure that init_varasm_once is actually identical
> >>> to what the CTOR does?
> >>
> >> So you want asm_out_state::asm_out_state doing what we current initialize
> >> in init_varasm_once, right?
> >
> > Yes, asm_out_state should cover everything initialized in init_varasm_once
> > (and the called targetm.asm_out.init_sections).
> >
> > targetm.asm_out.init_sections would become
> >
> > asm_out_state *init_sections ();
> >
> > where the target can derive from asm_out_state (optionally) and
> > allocates the asm-out-state & invokes the CTORs.  The middle-end
> > visible asm_out_state would contain all the tables initialized in
> > init_varasm_once.
> >
> > I'm not sure if doing it piecemail is good - we don't want to touch
> > things multiple times without good need and it might be things
> > turn out not be as "simple" as the above plan sounds.
> >
> > I would suggest to try the conversion with powerpc since it
> > seems to be the only target with two different implementations
> > for the target hook.
> >
> > The
> >
> > static GTY(()) section *read_only_data_section;
> > static GTY(()) section *private_data_section;
> > static GTY(()) section *tls_data_section;
> > static GTY(()) section *tls_private_data_section;
> > static GTY(()) section *read_only_private_data_section;
> > static GTY(()) section *sdata2_section;
> >
> > section *toc_section = 0;
> >
> > could become #defines to static_cast<rs6000_asm_out_state *>
> > (casm)->section_name
> > and there'd be
> >
> > class rs6000_asm_out_state : public asm_out_state
> > {
> > ... add stuff ...
> > }
> >
> > in rs6000/xcoff.h and rs6000/sysv4.h and some generic rs6000 header as well
> > (adding no fields) and the target hook would basically do
> >
> >   return ggc_new rs6000_asm_state ();
> >
> > (OK, ggc_alloc + placement new I guess).  The default hook just
> > creates asm_out_state.
>
> Hello.
>
> All right, I made a patch candidate that does the suggested steps and I ported
> rs6000 target (both ELF and XCOFF sub-targets).
>
> So far I was able to bootstrap on ppc6le-linux-gnu.
>
> Thoughts?

+extern GTY(()) rs6000_asm_out_state *target_casm;

this seems to be unused

+#define rs6000_casm static_cast<rs6000_asm_out_state *> (casm)

maybe there's a better way?  Though I can't think of one at the moment.
There are only 10 uses so eventually we can put the
static_cast into all places.  Let's ask the powerpc maintainers (CCed).

Note you do

+/* Implement TARGET_ASM_INIT_SECTIONS.  */
+
+static asm_out_state *
+rs6000_elf_asm_init_sections (void)
+{
+  rs6000_asm_out_state *target_state
+    = new (ggc_alloc<rs6000_asm_out_state> ()) rs6000_asm_out_state ();
+  target_state->init_elf_sections ();
+  target_state->init_sections ();
+
+  return target_state;
+}

If you'd have made init_sections virtual the flow would be more
natural and we could separate section init from casm construction
(and rs6000 would override init_sections but call the base function
from the override).

Alternatively asm_out_state::init_sections could move into the
CTOR itself so the target hook doesn't need to explicitely call it
(I guess I prefer that variant).

Otherwise looks great - there are of course a few other targets
left to fixup.

Thanks,
Richard.

> Thanks,
> Martin
>
> >
> > Richard.
> >
> >> Thanks,
> >> Cheers,
> >> Martin
> >>
> >>
> >>>
> >>> Richard.
> >>>
> >>>> Thanks,
> >>>> Martin
> >>

  reply	other threads:[~2021-10-21 12:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  9:31 [PATCH][RFC] Come up with casm state Martin Liška
2021-09-16 10:00 ` [PATCH 1/N] Rename asm_out_file function arguments Martin Liška
2021-09-16 13:52   ` Iain Sandoe
2021-09-17  8:23     ` Richard Biener
2021-09-17  9:42       ` Iain Sandoe
2021-09-17  9:57         ` Richard Biener
2021-10-20 11:57   ` Martin Liška
2021-10-20 12:11     ` Richard Biener
2021-09-16 10:00 ` [PATCH 2/N] Do not hide asm_out_file in ASM_OUTPUT_ASCII Martin Liška
2021-09-22  9:44   ` Richard Biener
2021-09-30 11:46     ` Martin Liška
2021-09-16 13:12 ` [PATCH 3/N] Come up with casm global state Martin Liška
2021-09-22  9:59   ` Richard Biener
2021-10-04 11:13     ` Martin Liška
2021-10-05 11:54       ` Richard Biener
2021-10-21  9:47         ` Martin Liška
2021-10-21 12:42           ` Richard Biener [this message]
2021-10-21 13:43             ` Martin Liška
2021-10-21 13:57               ` Richard Biener
2021-10-21 15:40             ` Segher Boessenkool
2021-10-25 10:46               ` Richard Biener
2021-10-25 13:36                 ` Martin Liška
2021-10-25 16:30                   ` Segher Boessenkool
2021-10-26  7:45                     ` Richard Biener
2021-11-05 14:27                       ` Martin Liška
2021-11-09 12:49                         ` Richard Biener
2021-10-25 16:06                 ` Segher Boessenkool
2021-10-04 11:16   ` Martin Liška
2021-10-21 12:47   ` David Malcolm
2021-10-21 13:08     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc2K-VTMBRQTg=F8A3Ee5ph0+7-Pv_aotO8HaAS6MN_42A@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).