You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some vendor intrinsics come with various constants defined that give special meaning to integer values. The _SIDD_* constants, for example, are used with the packed compare intrinsics.
What should we do about these? Should we define them at all? If we do, should they go in their own separate module, or should they live in the same flat namespace as the rest of the intrinsic functions?
The text was updated successfully, but these errors were encountered:
If we do, should they go in their own separate module, or should they live in the same flat namespace as the rest of the intrinsic functions?
Right now they live in the same module, which is what the C API does (and any "nicer" solution won't be what C does).
Having said this, there aren't that many constants, so we could put them in their own modules.
Currently we are basically dumping everything in the vendor module, so this is at least tangentially related to: how "clean" do we want vendor to be? The answer to this question doesn't need to be the same for all architectures.
Some vendor intrinsics come with various constants defined that give special meaning to integer values. The
_SIDD_*
constants, for example, are used with the packed compare intrinsics.What should we do about these? Should we define them at all? If we do, should they go in their own separate module, or should they live in the same flat namespace as the rest of the intrinsic functions?
The text was updated successfully, but these errors were encountered: