Re: Fw: [PATCH 1/2] BZ#13743: PowerPC - Add a new header forplatform specific functions

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Fri, 2012-03-09 at 10:35 -0500, David Edelsohn wrote:
> On Thu, Mar 8, 2012 at 6:00 PM, Steven Munroe
> <munroesj@linux.vnet.ibm.com> wrote:
> > On Thu, 2012-03-08 at 15:22 -0500, Michael Meissner wrote:
> >> Steven Munroe <munroesj@linux.vnet.ibm.com> wrote on 03/08/2012 12:29:23
> >> PM:
> >>
> >> > Bringing David and Michael into the conversation.
> >> >
> >> > > > We need these to APIs to be easy to find, documented, and durable (a
> >> > > > commitment to be there in the next release).
> >> > >
> >> > > Do you feel then that the GCC community is unable to make this
> >> commitment?
> >> > >
> >> > Well as a Toolchain Architect I can see a separation between language
> >> > issues and APIs where GCC is focused on language and GLIBC is focused on
> >> > APIs. And I would put the timebase and program priority register into
> >> > the API category.
> >> >
> >> > So the GCC community can and does make such commitments (for example the
> >> > __sync_fetch_and_* builtins) that can be implemented cross platform. But
> >> > I can see where they might decide that this specific case is not a good
> >> > example for GCC to carry.
> >> >
> >> > But I should let David and Michael speak for themselves.
> >> >
> >> > > The GLIBC community could certainly make such a commitment, but final
> >> > > responsibility rests with you and Ryan as the official power maintainers.
> >>
> >> My opinion is that in the case of timebase, there should be a ppc get timebase
> >> builtin in the compiler, that on 32-bit generates the 3 mfspr's, compare, and
> >> branch and on 64-bit just the single mfspr.
> >>
> >> In general, things like this should be in the compiler, since the compiler can
> >> adjust costs, etc. and schedule insns, while just doing them as random asms
> >> means the code is just a blob that the compiler can't schedule arround.  Of
> >> course you can get to having too many builtins (one might argue we are already
> >> there), but in this case, I think the compiler should provide the builtin.
> >> Obviously you have a staging issue, where it might be useful for platform.h or
> >> ppc-platform.h or whatever does an #ifdef and if the compiler is new enough,
> >> just generate the builtin, otherwise generate the asms.
> >>
> >
> > Michael it seems you are responding specifically to timebase and not
> > general question (program priority register and data stream control
> > register, etc). Or are you accepting the larger set?
> >
> > Even with Michael gracious offer there are timing and availability
> > issues since any new builtins would be GCC-4.8.
> 
> Steve,
> 
> You appear to have some mental model about the set of intrinsics that
> you want defined; I don't know your list.  GCC often has provided
> headers, macros, builtins, intrinsics for instructions related to the
> computation and synchronization, e.g., SIMD, locking, etc.  But GCC is
> not meant as a catch-all for every architecture feature.

Ok, as I understand that GCC could be a home for intrinsics for
computation and synchronization but not a catch-all. This is very close
to my assumption above. But you may being disagreeing with Michael on
the timebase?

I would assume that things like timebase, and program priority register
are more strongly associated with multi-core and threading APIs (ie
GLIBC)

How do you feel about the data stream control register and getting a
more complete set (than __sync_synchronize()) of memory barriers? *GCC
or GLIBC)?