[mips/mips64: msa] add add_a_b intrinsic

[gnzlbg]

This PR adds a single mips::msa intrinsic (add_a_b: vector add absolute values).

It adds all the scaffolding for adding more mips/mips64 intrinsics "easily" in the future.

• adds an arch::mips64 module
• generates documentation for mips/mips64
• adds run-time feature detection for mips/mips64 (auxiliary vectors only)
• adds simd_test support for mips/mips64 (requires parsing instructions as expressions instead of identifiers because add_a.b is a valid MIPS64 instruction name)

The following issues are left for future PRs:

• adding CI for MIPS: CI for MIPS/MIPS64 #364
• adding synthetic tests using the auxval crate: Add /proc/cpuinfo support for mips64 #355
• adding cpuinfo support: Add synthetic auxiliary vector tests for mips64 #354

---

@alexcrichton I cleaned up the run-time feature detection on linux a bit because it was getting out-of-hand. I have no idea whether this might break rustc builds or not. Is there a way for me to test this? If these changes break some build bots there, we should add these build bots to our CI as well.

cc @jcowgill

[alexcrichton]

Looks good! My main comment is to try to reduce the amount of #[cfg] as it looks like it'd be pretty difficult to otherwise maintain over time

[alexcrichton]

Could this use the -p argument to avoid changing the cwd?

[gnzlbg]

Sure thing.

[alexcrichton]

This unfortunately will cause some problems when building in libstd itself as this doens't exist, but could this continue to use the same strategy as before?

[alexcrichton]

I'm personally not a huge fan of #[cfg] as it can make already complicated code even more complicated, so could this continue to compile on all platforms and just statically return an error on the "wrong" platforms?

[gnzlbg]

IIRC the problem here was that the auxvec/cpuinfo modules are only available on some oses (currently only linux), but these functions should be available on all OSes and just return nothing on linux.

So IMO the entanglement here is that we have target_os modules (e.g. linux) and arch modules (e.g. aarch64) and a mixture of archs and target_oses on both. I'll try to think of something better here.

[alexcrichton]

Perhaps cfg_if! could be used to simplify this? That could be added as a dependency and it's available in libstd as well

[alexcrichton]

Could both fields be perhaps unconditionally included to avoid the extra #[cfg] traffic?

[alexcrichton]

Ideally I'd prefer to avoid the #[cfg] here, it becomes a pretty big burden to maintain over time :(

[alexcrichton]

Oh sorry I meant -p arguments to the cargo commands :)

[gnzlbg]

@alexcrichton So I think I managed to clean up cfg-hell at least a bit. The gist in a nutshell is:

stdsimd/detect/ now has two sub-directories:

• stdsimd/detect/arch/{target_arch}.rs: provides the Feature enum and the is_{target_arch}_feature_detected! macros - these are arch-dependent, but os independent.

• stdsimd/detect/os/{target_os}.rs: defines the platform-dependent check_for function, that is, how features are actually detected on the different platforms (os + arch).

I don't think this is great, but I think it is better than what we had. Now, cpuinfo, auxvec, and the cache are only defined on the platforms that actually need them. For example, on non-x86 non-linux platforms we don't need the cache because we can't detect any features anyways.

[alexcrichton]

Alright looks good to me, thanks! We can always of course continue to tweak this over time

[gnzlbg]

Yes we will need to do so to add windows on arm support.

…

On Sat 10. Mar 2018 at 19:23, Alex Crichton ***@***.***> wrote: Alright looks good to me, thanks! We can always of course continue to tweak this over time — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#365 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3Npo8ZPBn1KcLSM9jzJkSOAw6bNDumks5tdBoNgaJpZM4SkamW> .