On 2/5/20 6:30 AM, Segher Boessenkool wrote:
Hi!
On Wed, Feb 05, 2020 at 08:57:16AM +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt 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.
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)
One thing that's powerpc-unique (I believe) is our peculiar overloading
infrastructure for the original AltiVec interface (extended to cover
quite a bit more territory since). But that's largely an extra level of
abstraction that could eventually be optional.
There's also some specificity to our vector types (things like vector
bool and vector pixel) that would need to be abstracted away.
Finally, there's a set of flags for special handling that are definitely
Power-specific and would have to be abstracted away also.
Nothing that couldn't be dealt with given enough attention, so far as I
can see. But honestly I have not looked a great deal into other
targets' built-in handling to see what other landmines might be present.
Absolutely, but we first want to solve the urgent problem for Power
(because that is what it is); it's a huge job with that reduction of
scope, already. After *that* is done, it will be clearer how to do
things for what is wanted generically, will be clearer what is wanted
in the first place :-)
Yes, this is a necessary first step to even be able to see what's going
on...
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.
I think there will be too many problem cases, a direct description of
the builtins will work better (but is more verbose of course).
In any case, Bill's patches keep the exact same approach in rs6000 as
we had before, just with some more pre-processing and macros etc.;
which results in a much shorter description, many cases folded into one,
which as a bonus also fixes bugs (directly, when two things you fold
should be the same but are not, at least one of them is wrong; and maybe
more importantly indirectly: a reader of the tables will spot errors
much more easily if they fit on one screen, if you have similar entries
on the screen at the same time so you *can* compare; and there will be
more readers as well even, people are actually scared of having to look
at it currently).
So, yes, this same approach might be a good fit generically, but we'll
do it for rs6000 only, in the interest of ever getting it done ;-)
The generator programs etc. can move to generic code later, if that
helps and there is interest in it, there isn't much (if anything) in
here that is specific to our arch.
I'll keep this possibility in mind as we move forward. It's probably a
matter of months to get everything converted over just for Power. But
this set of patches is the most generic; the remaining patches will all
be quite Power-specific.
Thanks,
Bill
Segher
