Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using CBLAS_INDEX and CBLAS_INT integer types in CBLAS #588

Merged

Conversation

weslleyspereira
Copy link
Collaborator

@weslleyspereira weslleyspereira commented Jun 23, 2021

Description

Some of the collaborators think it is a good idea to have two indexes in CBLAS, let's say CBLAS_INDEX and CBLAS_INT (See the discussion in #461). In fact, this was the behavior in CBLAS before 4177968. Moreover, two indexes are still being used in MKL (CBLAS_INDEX and MKL_INT) and OpenBLAS (CBLAS_INDEX and blasint).

In this PR:

  1. We move back to a cblas.h that uses two integer definitions, CBLAS_INDEX and CBLAS_INT. CBLAS_INDEX will only be used in the return of cblas_i*amax. With that, we restore an ABI that is compatible with other BLAS.
  2. We choose the default value of CBLAS_INDEX to be size_t.

I am sure we have pros and cons regarding (2), and I hope we can discuss them in this thread.

Additional information:

  • As in CBLAS before 83fc0b4, we expect the Fortran subroutine returns a signed integer of type CBLAS_INT. Therefore, cblas_i*amax must convert the return value to CBLAS_INDEX.
  • OpenBLAS, MKL, GNU Scientific Library, and Numpy all use CBLAS_INDEX = size_t by default.
  • The C interface for BLAS (https://www.netlib.org/blas/blast-forum/cinterface.pdf) indicates that, usually, CBLAS_INDEX = size_t.

Checklist

  • The documentation has been updated
  • If the PR solves a specific issue, it is set to be closed on merge.

@langou langou merged commit e886613 into Reference-LAPACK:master Aug 30, 2021
@julielangou julielangou added this to the LAPACK 3.10.1 milestone Nov 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants