Add support for unaligned simd masked load/store

[sayantn]

We currently have only an aligned version of simd_masked_load, but the underlying llvm intrinsic doesn't have any alignment requirement. So I propose to add simd_masked_load_unaligned and simd_masked_store_unaligned. These will link with the llvm intrinsic with an alignment of 8 bits (the lowest permissible in Rust)

[workingjubilee]

The alignment required is only the alignment of the T for the Simd<T, N>.

[workingjubilee]

Do you have a use-case in mind?

[workingjubilee]

Oh, I see. It seems this is about rust-lang/stdarch#1594 yes? Except you have underaligned loads and stores, also!

I think I'd rather see us pass the alignment as a const generic parameter if we want to go down this road, then we can pass 1 or whatever.

[sayantn]

Yes, this is for stdarch. There are a lot of unaligned masked load/store intrinsics, and they all resort to using inline asm.

[workingjubilee]

the aligned ones also, thus my remark about a generic alignment. (at least, I hope emitting the correct alignment would encourage LLVM to lower things correctly...)

[sayantn]

Even if we add a generic alignment parameter, most if not all use cases will be fully-aligned or fully-unaligned. Also, having a random ::<1> in the middle of simd code will be somewhat confusing

[workingjubilee]

For who? Standard library developers?

I agree it doesn't have many possible values though.

[sayantn]

For any contributor, it may be confusing. I think stdarch code should be as clear as possible to avoid possible bugs

[sayantn]

The only practical values are 1, 2, 4 and 8

[workingjubilee]

The only practical values are 1, 2, 4 and 8

Not if you want to emit vmovaps. That puts 16, 32, and 64 on the table.

And I understand that desire, but I also think that the compiler code implementing these intrinsics should be as clear as possible to avoid possible bugs.