On Jan 28, 2012, at 6:07 PM, Dmitri Gribenko wrote:
> My colleague and I want to implement a compile-time check (warning)
> for clang compiler that specified buffer type matches passed
> MPI_Datatype.
Interesting!
> Here's what is required on the OpenMPI part: all MPI functions that
> accept a buffer and MPI_Datatype should be annotated with
> mpi_typed_arg(buffer-arg-index, type-arg-index) attribute. For
> example:
>
> int MPI_Send(void *buf, ...etc...) __attribute__(( mpi_typed_arg(1,3) ));
This isn't terrible; we do similar things throughout the code base.
Will you be able to do this for MPI functions that take 2 choice buffers?
E.g., MPI_Gather.
> Predefined datatypes should be annotated with corresponding C types:
> mpi_datatype(var-decl-with-corresponding-type):
>
> extern int ompi_mpi_int_dummy;
> extern struct ompi_predefined_datatype_t ompi_mpi_int
> __attribute__(( mpi_datatype(ompi_mpi_int_dummy) ));
Just to make sure I understand this syntax: is ompi_mpi_int_dummy just to
indicate the *type* that is congruent with the ompi_predefined_datatype_t?
I.e., I'd do something like this for MPI_DOUBLE:
extern double ompi_mpi_double_dummy;
extern struct ompi_predefined_datatype_t ompi_mpi_double
__attribute__(( mpi_datatype(ompi_mpi_double_dummy) ));
?
> Users can annotate their types too:
> int my_int_dummy;
> MPI_Datatype my_int_type __attribute__(( mpi_datatype(my_int_dummy) ));
More importantly, can they do:
struct my_struct_t my_struct_dummy;
MPI_Datatype my_struct_type __attribute__(( mpi_datatype(my_struct_dummy) ));
?
> This design is not final, I'd really like to have mpi_datatype(type)
> (e.g., mpi_datatype(long long)) but clang doesn't currently have
> support for parsing that. (But I think that clang developers won't
> accept the patch unless we implement that). So type annotations will
> probably look like:
>
> extern struct ompi_predefined_datatype_t ompi_mpi_int
> __attribute__(( mpi_datatype(int) ));
That would certainly be better.
> The attributes can be hidden with macros from compilers that don't
> support them, so compatibility should not be a problem.
Yep -- we have a bunch of those already.
> I would like to hear if there is any issue with this idea or
> implementation design that could prevent the corresponding patch for
> mpi.h to be accepted.
I'm supportive of this (mpi.h.in, you mean :-) ).
Depending on the patch, however, we might need a signed Open MPI contribution
agreement from you/your employer (it's essentially the Apache Foundation
agreement with s/Apache/Open MPI/g). It's annoying, I know :-(, but we have to
keep the intellectual property of Open MPI "clean" so that it can guaranteed to
remain BSD:
http://www.open-mpi.org/community/contribute/
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
