3 ms·

The SIMD crate doesn't uses fast load intrinsics for loads instead it falls back on derviving clone/copy. Honestly it should have a manual derefence trait as we

The SIMD crate doesn't uses fast load intrinsics for loads instead it falls back on derviving clone/copy. Honestly it should have a manual derefence trait as well. Also now that naked functions are implemented it should use these to (?). I can't patch this because I don't understand rust-macro's well enough to submit a PR against Huown's (sp?) crate. Which because these are repetitive traits/functions it abstracts away. So I go to write my own and find out __m128 load (either alligned or un-alligned) LLVM intrinsic isn't part of the rust-compiler. (Or __m256, or __m512) Soooo When I submitted a PR with changes for these LLVM intrinsics I was told that I was editing an auto generated Rust file. Instead I need to modify a series of JSON files+Python script. I gave up at that point. If we could just modify the intrinsic file directly that'd be helpful. Yes it'll be big and ugly, but so is every compilers SIMD source section. The current JSON based approach is annoying. Also a lot more JSOn files are needed for things that aren't SSE/AVX like MPX and Crypto extensions. Lastly the JSOn syntax feels bloated and ugly compared to Rust syntax so it is easier to understand args/typing requirements.

sanxiyn 10y ago
Can you link the PR? I am interested in getting it merged. I assume you are referring to code generator at https://github.com/rust-lang/rust/tree/master/src/etc/platform-intrinsics https://github.com/rust-lang/rust/tree/master/src/etc/platfo.... I haven't touched that code, but if you think hand editing is preferrable to code generator in terms of maintenance, and everybody agrees, I am sure it can be deleted and generated code be hand edited from now on. For others, here is an example PR adding AVX compare and blend to Rust, and how does change to JSON and change to generated Rust code compare: https://github.com/rust-lang/rust/pull/32231 https://github.com/rust-lang/rust/pull/32231
- valarauca1 10y ago
  >Can you link the PR? I am interested in getting it merged. Sadly no. I had to delete my old github account due to IRL harresment. I can resubmit later tomorrow.
  - sanxiyn 10y ago
    Thanks a lot. Please cc me when you resubmit, I'm sanxiyn (same ID) on GitHub.
dbaupp 10y ago
The JSON file exists because there's more than one place that needs to know about the intrinsics---they allow generating the corresponding `extern` blocks---and because there's classes of very similar functions that can be factored out into a single definition. Keeping things in sync manually is error prone and exceedingly annoying. However, I agree that the JSON syntax is a... slightly complicated. In any case, I'm not sure why you think you need a separate load intrinsic: the compiler knows how to generate code for loading data. E.g. if you know data is aligned, casting to a `*const i32x4` and loading that does the right thing. The unaligned case is a little more subtle but it also can be made to work via #[repr(packed)].
- sanxiyn 10y ago
  I think when we receive PR modifying generated Rust code, we should say "that's autogenerated; can you change JSON instead? If you think it's too much, we can figure out JSON change ourselves". I think the later half is important.
- valarauca1 10y ago
  >They allow generating the corresponding `extern` blocks Really? I was able to call the intrinsic I sloppy patched into the auto generated files fine via extern platform. >In any case, I'm not sure why you think you need a separate load intrinsic Because it's a systems programming language?
  - dbaupp 10y ago
    > Really? I was able to call the intrinsic I sloppy patched into the auto generated files fine via extern platform. Err... yes, that is exactly my point. You needed an `extern` block to call the functions. It is much nicer if the `extern` block is written down once (just like the _mmintrn.h files for gcc/clang) so that there's no risk of mistakes or mismatches. The JSON files make this easy: both the compiler internals and the external `extern` block are guaranteed to match. Note that this is particularly important on a platform like AArch64, where there are hundreds of intrinsics: hand-transcribing them twice (once for the compiler, once for the libraries) is time consuming and error-prone. > Because it's a systems programming language? This is meaningless: being a systems language doesn't mean having intrinsics for every possible operation, it just means being able to do everything; these are not the same. The remainder of the paragraph you quoted explained how the functionality already exists. The only benefit of having an intrinsic function to call is that there is a function instead of built-in syntax, it doesn't add any new power: Rust is just as systems-y with or without the intrinsic.

sanxiyn 10y ago

Can you link the PR? I am interested in getting it merged. I assume you are referring to code generator at https://github.com/rust-lang/rust/tree/master/src/etc/platform-intrinsics https://github.com/rust-lang/rust/tree/master/src/etc/platfo.... I haven't touched that code, but if you think hand editing is preferrable to code generator in terms of maintenance, and everybody agrees, I am sure it can be deleted and generated code be hand edited from now on. For others, here is an example PR adding AVX compare and blend to Rust, and how does change to JSON and change to generated Rust code compare: https://github.com/rust-lang/rust/pull/32231 https://github.com/rust-lang/rust/pull/32231

valarauca1 10y ago
>Can you link the PR? I am interested in getting it merged. Sadly no. I had to delete my old github account due to IRL harresment. I can resubmit later tomorrow.
- sanxiyn 10y ago
  Thanks a lot. Please cc me when you resubmit, I'm sanxiyn (same ID) on GitHub.

dbaupp 10y ago

The JSON file exists because there's more than one place that needs to know about the intrinsics---they allow generating the corresponding `extern` blocks---and because there's classes of very similar functions that can be factored out into a single definition. Keeping things in sync manually is error prone and exceedingly annoying. However, I agree that the JSON syntax is a... slightly complicated. In any case, I'm not sure why you think you need a separate load intrinsic: the compiler knows how to generate code for loading data. E.g. if you know data is aligned, casting to a `*const i32x4` and loading that does the right thing. The unaligned case is a little more subtle but it also can be made to work via #[repr(packed)].

sanxiyn 10y ago
I think when we receive PR modifying generated Rust code, we should say "that's autogenerated; can you change JSON instead? If you think it's too much, we can figure out JSON change ourselves". I think the later half is important.
valarauca1 10y ago
>They allow generating the corresponding `extern` blocks Really? I was able to call the intrinsic I sloppy patched into the auto generated files fine via extern platform. >In any case, I'm not sure why you think you need a separate load intrinsic Because it's a systems programming language?
- dbaupp 10y ago
  > Really? I was able to call the intrinsic I sloppy patched into the auto generated files fine via extern platform. Err... yes, that is exactly my point. You needed an `extern` block to call the functions. It is much nicer if the `extern` block is written down once (just like the _mmintrn.h files for gcc/clang) so that there's no risk of mistakes or mismatches. The JSON files make this easy: both the compiler internals and the external `extern` block are guaranteed to match. Note that this is particularly important on a platform like AArch64, where there are hundreds of intrinsics: hand-transcribing them twice (once for the compiler, once for the libraries) is time consuming and error-prone. > Because it's a systems programming language? This is meaningless: being a systems language doesn't mean having intrinsics for every possible operation, it just means being able to do everything; these are not the same. The remainder of the paragraph you quoted explained how the functionality already exists. The only benefit of having an intrinsic function to call is that there is a function instead of built-in syntax, it doesn't add any new power: Rust is just as systems-y with or without the intrinsic.