This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] split of i386.c
- From: Jeff Law <law at redhat dot com>
- To: Eric Gallager <egall at gwmail dot gwu dot edu>, Martin Liška <mliska at suse dot cz>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, 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: Tue, 12 Mar 2019 14:54:23 -0600
- Subject: Re: [RFC] split of i386.c
- References: <b2f2be9b-a86c-6d8f-4053-bbd0ef8540d4@suse.cz> <CAMfHzOsh7gX8y7QRQJjwP-aGzch0VHM0UWqGqcko=N4zfu66JQ@mail.gmail.com>
On 3/12/19 2:50 PM, Eric Gallager wrote:
> On 3/12/19, Martin Liška <mliska@suse.cz> 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?
>>
>> Thanks,
>> Martin
>>
>
> I'm not a maintainer, but just as an onlooker I highly support this
> move; i386.c is way too long as it is. 7 pieces sounds like a good
> number of new files to split it into, too.
I trust your judgment on where/how to split and fully support the goals
behind splitting. Uros is the key person you need to get on board.
jeff