Re: [PATCH] Fix builtin attributes on powerpc

[David Edelsohn <dje.gcc@gmail.com>]

On Wed, Oct 14, 2009 at 11:15 AM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:

> Unfortunately, I'm not sure I can do all of this in the time remaining.  I
> suspect it will take at least 5 days of time to build the infrastructure to do
> what rth and richi have asked for.  The goals as I see it are:
>
>  1) Move the creation of the MD builtins to be part of the normal builtin
>     creation, in a seamless fashion without forcing the backends to have a
>     flag day changing their builtin handling (originally from rth).  Part of
>     this was done in this RFC patch that provided the new infrastructure:
>     http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01820.html
>
>  2) Allow for lazy creation of the trees for builtin functions and types
>     (originally from richi).  I know where the places that need to be modified
>     are, but it will involve changes in both the front ends and middle end to
>     do this.  This will take some amount of time to get right.
>
>  3) Move all of the rs6000 builtins (the various bdesc tables in rs6000.c) to
>     this new scheme.  Just due to the number of builtins that exist in the
>     rs6000 backend, this will take some time to make sure all of the types,
>     etc. are properly created.
>
>  4) Then possibly get x86, arm, etc. to move to the new scheme.
>
> However, I can't do #3 until at least the infrastructure changes are in place,
> and given we are in stage 3 right now, I don't think this is the time for doing
> it.  Thus the 2 different patches that I have submitted are a stopgap measure
> for the 4.5 time frame, until the infrastructure is done in the 4.6 time frame.
> One patch is just a big switch statement that identifies the problematical
> builtins, and the second patch just creates a .def file to define both the enum
> id, and attributes to use.  To me they are semantically identical, and I can
> easily go back to the switch statement if the issue is the creation of a new
> file is the issue.
>
> Right now, I have several codegen issues in the power7 code that need to be
> fixed before 4.5 goes out, and I judge that these are more important than
> getting the attributes correct, given the 4.4 backport has worked around the
> problem that started this set of patches.
>
> I can spend the odd hour here and there making the patch more acceptable, but I
> don't feel I can spend the week or two of time right now doing the scheme the
> right way so that it won't have to be reworked in the 4.6 time frame and
> possibly send out 4.5 where several benchmarks are getting miscompiled.  It
> would be nice to get the power backend to have pairity with the x86 to at least
> set NOTHROW and READONLY where appropriate.
>
> I wish I had known about the issue earlier and could have gotten the
> infrastructure in before stage1 closed, but that's the breaks.

I am not asking for the design to be implemented for all ports and I
am not asking that the entire design be implemented for the rs6000
port.  I want to make sure that the interim patch for 4.5 is
consistent with the direction the community wants to take for 4.6 so
that we do not end up maintaining a special hack indefinitely.

David