This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] split of i386.c
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jan Hubička <honza dot hubicka at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 13 Mar 2019 08:55:04 -0400
- Subject: Re: [RFC] split of i386.c
- References: <b2f2be9b-a86c-6d8f-4053-bbd0ef8540d4@suse.cz>
On Tue, 2019-03-12 at 16:08 +0100, Martin Liška wrote:
> Hi.
>
> I've thinking about the file split about quite some time, mainly
> in context of PR84402. I would like to discuss if it's fine for
> maintainers of the target to make such split and into which logical
> components can the file be split?
>
> I'm suggesting something like:
> - option-related and attribute-related stuff (i386-options.c - as
> seen in patch)
> - built-in related functions
> - expansion/gen functions - still quite of lot of functions, would
> make
> sense to split into:
> - scalar
> - vector
> - prologue/epilogue, GOT, PLT, symbol emission
> - misc extensions like STV, TLS, CET, retpolines, multiversioning, ..
> - helpers - commonly used functions, print_reg, ix86_print_operand,
> ..
>
> I am volunteering to make the split, hopefully early in the next
> stage1.
>
> Thoughts?
IIRC we had a policy that new C++ source files (as opposed to tests)
get a .cc extension, rather than .c
I'm not sure if that applies in the case of a split like this one.
Dave