On Feb 4, 2020, at 9:40 AM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >> 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.
Or, config/gen-builtins. :-) We have one around here, and there are things that a generator can have that are really, generally useful. It's better to share support for common thing and for very target specific things, of course, they can go down in the rs6000 area. Our generators are written in python, and for this type of code, python is nice. My workflow with my generators let's me validate changes to the generator easily, as I can compare a before and after of the generated content. Once you push the common parts down and invite others to join the party, the next port can reuse the bits you have, and add the 1 or 5 things they need, and presto, you now have more beef, should you need it in the future. Around here, we have more beef than anyone, as we always hit things no one else has. In/out rtl parameters, out parameters, overloading, test case generation, early, late expansion, type fun, vector fun, architecture fun, optional parameters, gosh, the list just goes on and on... Anyway, as a new port comes on line, it's easier for them to retrofit the 3 new things they need into a nice infrastructure that sings and dances. Indeed, some of the older gcc port interfaces, for example, registers (FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS, REG_ALLOC_ORDER, HARD_REGNO_CALLER_SAVE_MODE, REG_CLASS_NAMES, REG_CLASS_CONTENTS, REGISTER_NAMES), I think would be a nice area for a generator as well. Every port has registers, and yet, those interfaces are too clunky. But, now I guess I digress. Just wanted to say, I like your plan.
