On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > Hi! > > On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote: > > The current built-in support in the rs6000 back end requires at least > > a master's degree in spelunking to comprehend. It's full of cruft, > > redundancy, and unused bits of code, and long overdue for a > > replacement. This is the first part of my project to do that. > > Woohoo :-)
Indeed. > > My intent is to make adding new built-in functions as simple as adding > > a few lines to a couple of files, and automatically generating as much > > of the initialization, overload resolution, and expansion logic as > > possible. This patch series establishes the format of the input files > > and creates a new program (rs6000-genbif) to: > > Let's call it rs6000-gen-builtins or similar. Not as cryptic. I believe we talked about this a few years ago. Any reason this is powerpc specific? If sufficiently generic most targets would benefit and maybe even frontends and the middle-end could make use of this. The generator program, that is. (disclaimer: I didn't look into the patches at all) I always wondered if we can make our C frontend spit out things from C declarations (with maybe extra #pragmas for some of the more obscure details) and how to fit that into the bootstrap. > > Note that none of the code in this patch set affects GCC's operation > > at all, with the exception of patch #14. Patch 14 causes the program > > rs6000-genbif to be built and executed, producing the output files, > > and linking rs6000-bif.o into the executable. However, none of the > > code in rs6000-bif.o is called, so the only effect is to make the gcc > > executable larger. > > If it builds at all ;-) > > > I'd like to consider at least patches 1-13 as stage 4 material for the > > current release. I'd prefer to also include patch 14 for convenience, > > but I understand if that's not deemed acceptable. > > > > I've attempted to break this up into logical pieces for easy > > consumption, but some of the patches may still be a bit large. Please > > let me know if you'd like me to break any of them up. > > I will. "Large" isn't a problem if it is a lot of the same thing. If > it is two or more things, having them in separate patches is easier to > review; if there is just one case that is different, put it in a separate > patch if that can be done; otherwise, please point it out in the patch > commit message. > > > Initial create of rs6000-genbif.c. > > Subjects do not end in a dot (but do start with a capital). > > > Add stubs for input files. These will grow much larger. > > The second half of this does not belong in the title, but in the body. > > > Segher
