[cfe-commits] [PATCH] Compile-time MPI_Datatype checking, type arguments in attributes

[Hal Finkel]

On Sun, 2012-02-12 at 19:02 +0200, Dmitri Gribenko wrote:
> Hi Hal,
> 
> Thank you for looking into this!
> 
> On Sun, Feb 12, 2012 at 6:22 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > 1. How much of this is realy MPI specific? Maybe I'm wrong, but the
> > general idea is to add type checking for APIs that take void* along with
> > some kind of tag indicating the actual data type. MPI may be a primary
> > use case, but that general situation seems not uncommon. I wonder if we
> > could take 'mpi' out of the syntax and replace it with some kind of
> > domain tag. For example, instead of mpi_typed_arg(1,3) we might name it
> > pwt_arg("mpi",1,3) [pwt = pointer with tag] and use pwt_type("mpi",int).
> 
> There are two MPI-specific points:
> 1. void* pointers don't trigger a warning (to support wrapping MPI
> calls and passing NULL, MPI_IN_PLACE).
> 2. void datatype is tied to the special case of MPI_DATATYPE_NULL and
> we complain if a non-NULL pointer was passed.
> 
> If we are going to generalize this (which is a good idea in itself),
> we should define the semantics of pwt_arg(kind,ptr-idx,type-idx) where
> `kind' is not known to the compiler.

I don't think that the compiler needs to know about any particular
'kind's, we can use arbitrary string tags. The idea is just to allow for
multiple classes of tags to go along with different APIs. I think that
your point 1 is appropriate for any API. Point 2 can be optionally
enabled with some attribute tag.

My answer to your question is that the compiler should do nothing in
that case. Regarding the buffer type, the compiler should warn only if
understands the type tag used and knows that the type of the buffer is
incorrect for tag used. We may also want a warning when the tag used is
a constant and not one in the appropriate list, etc.

> If the compiler is required to
> make checks, we have to specify them (and that should be a subset of
> the checks that are done by every known tag).
> 
> If the compiler should ignore such attribute, then what does this buy
> us compared with MPI-specific attribute name?

See above, I was just suggesting API neutrality. I think that the
semantics are pretty universal.

> 
> > 2. Supporting MPICH-derived implementations will be important. Maybe we
> > could add a pragma to allow the definition of integer-type tags. [I may
> > be slightly biased here ;) -- a bunch of the MPICH developers work down
> > the hall from me -- but it would be great to have something like this
> > installed for our users here]. Especially if we make this slightly more
> > generic, supporting integer/enum tags will be necessary.
> 
> Here's what MPICH currently does:
> #define MPI_INT ((MPI_Datatype) 0xMAGIC)
> 
> I don't think pragmas can create a good solution.
> 
> Here's an example of what can be done.  In addition to defining the
> macros, MPICH could add some private constants to mpi.h:
> static const int mpich_datatype_int __attribute__(( mpi_datatype(int)
> )) = 0xMAGIC;
> 
> The compiler could build a map (integer tag -> type) from that.

Fair enough. I am not sure that 'const int' is quite right, but I
understand what you mean.

> 
> Dmitri
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory