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 :-)

> 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.

> 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

Reply via email to