Fix windows builds & add some travis windows builds

[gnzlbg]

i686-pc-windows-gnu is still not working on travis, but everything else should be green.

[alexcrichton]

Hm do you know why these tests need to be ignored on Windows? I haven't had a chance to dig in yet but this seems somewhat bad

[gnzlbg]

We are just getting different codegen on windows AFAICT. What was being generated looked "ok".

[gnzlbg]

By ok I mean that the fma intrinsics have a number (e.g. 213 or 123) indicating in which xmm{1-3} registers each argument is, and on windows a different one was being generated than on linux. For all others, extracts / inserts it appears that on windows things are being read/written to memory instead of to vectors.

[gnzlbg]

For example:

---- coresimd::x86::avx::assert__mm256_extractf128_si256_vextractf128 stdout ----
disassembly for coresimd::coresimd::x86::avx::assert__mm256_extractf128_si256_vextractf128::_mm256_extractf128_si256_shim: 
	 0: lea rax,[140150599h] 
	 1: mov rdx,qword ptr [__imp__ZN12stdsimd_test11_DONT_DEDUP17hd862070486ee008dE] 
	 2: mov qword ptr [rdx],rax 
	 3: mov qword ptr [rdx+8],49h 
	 4: vmovaps xmm0,xmmword ptr [rcx+10h] 
	 5: ret 
	 6: � 
thread 'coresimd::x86::avx::assert__mm256_extractf128_si256_vextractf128' panicked at 'failed to find instruction `vextractf128` in the disassembly', crates\stdsimd-test\src\lib.rs:163:9

Here it appears that the vector register is just directly read to memory instead of using vextractf128. I don't know why this is, I suspect that the vector arguments are passed somewhat differently on windows, and llvm decided that doing this is better than using vextractf128. The run-time tests still run and pass.

[alexcrichton]

Hm so in theory that should have all been fixed by this which tries to ensure the ABI has the registers coming in by-value so LLVM doesn't try to do anything tricky with optimizing the fact that they're already in memory.

It may be though that the ABI isn't what we want or that it was tweaked perhaps. In any case this seems fine by me, it seems highly unlikely anyway to have a Windows-specific bug here

[gnzlbg]

@alexcrichton do you have a codegen tests for that windows vectorcall ABI thing ? (I mean in rustc).

[alexcrichton]

Ah not in rustc afaik, apart from the standard "if we specify this does LLVM not crash?"

[gnzlbg]

I don't have a windows machine to test this, but maybe vectorcall is just not working correctly here ?

On godbolt things just work without any ABI: https://rust.godbolt.org/z/Kkyzl2 - and they work better with vectorcall: https://rust.godbolt.org/z/ofFtAy

[alexcrichton]

Oh hey looks like this may work! -- https://rust.godbolt.org/z/GARM_K

[alexcrichton]

Oh I should mention the ABI isn't required, the problem is that the ABI for Windows (I think) differs from the ABI for Unix, where Unix passes more things in registers than Windows. The fact that the Windows default ABI passes more things via memory causes the codegen differences on Windows/Unix. The attempt with vectorcall was to change ABIs on Windows to something that passes more arguments via registers, but it looks like that didn't work. The sysv64 ABI though may work!

[gnzlbg]

The sysv64 ABI though may work!

I've pushed a commit using it instead of vectorcall, we'll see what happens. Is there a list of ABIs that we support ?

[alexcrichton]

I was working off this list -- https://github.com/rust-lang/rust/blob/36a50c29f6c5c386fba6ab685818755ac55152e5/src/librustc_target/spec/abi.rs#L53-L77

[gnzlbg]

LLVM ERROR: stack allocation size is not a multiple of 8

:(

[alexcrichton]

alas!

[gnzlbg]

so I've reverted the last commit :/

[gnzlbg]

I've opened #594 to track this.