On Tue, Mar 12, 2019 at 9:54 PM Jeff Law <l...@redhat.com> wrote: > > On 3/12/19 2:50 PM, Eric Gallager wrote: > > On 3/12/19, Martin Liška <mli...@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.
I'm OK with the split, the file is getting huge and I think the suggested split would be beneficial. Uros.
