This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] split of i386.c


On Tue, Mar 12, 2019 at 9:54 PM Jeff Law <law@redhat.com> wrote:
>
> 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.

I'm OK with the split, the file is getting huge and I think the
suggested split would be beneficial.

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]