Add powerpc64 and powerpc64le support

[antonblanchard]

This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[eefriedman]

This looks suspicious; are you sure this should be 8, and not 16?

[antonblanchard]

Good catch, jemalloc should align to 16B on ppc64. testing this change now.

[eefriedman]

For reference, there's an associated PR against libc: rust-lang/libc#133 .

[eefriedman]

Are you sure this is correct? I think you're supposed to zero/sign-extend all integers less than 64 bits.

More generally, tests would be nice; there aren't any target-specific tests at the moment in rust/src/test/codegen/, but they would be good to have.

[antonblanchard]

This came straight from the cabi_powerpc32.rs version. You are right both powerpc32 and powerpc64 do need to sign extend smaller signed arguments.

I am somewhat confused by what the cabi code is required to do. It isn't modelling the ABI completely, because it would have to track actual GPR and FPR allocations to know when we are out of GPRs/FPRs and have to start using stack slots.

This small example appears to show powerpc64 rust sign extending as expected:

extern {
    fn one_arg(a: i64);
}

pub fn blah(x: i32)
{
    unsafe {
    one_arg(x as i64)
    }
}

  14:   b4 07 63 7c     extsw   r3,r3
  18:   01 00 00 48     bl      18 <_ZN4blah20heddc57cb357ff834kaaE+0x18>
                        18: R_PPC64_REL24       one_arg

[eefriedman]

That isn't the right testcase; try something like this:

#![crate_type="lib"]
extern {
    fn one_arg(a: i32);
}

pub fn blah(x: u64)
{
    unsafe {
    one_arg(x as i32)
    }
}

I think this should sign-extend (compare to the equivalent C void f(int); void g(unsigned long long x) { f(x) }).

[antonblanchard]

Thanks @eefriedman, that does show us zero extending incorrectly. I'm still uncertain as to how much of the ABI we need to model here. How does rust know when we run out of GPRs for parameters and it has to go to the stack for example?

[eefriedman]

LLVM's handling of the C calling convention is kind of awkward. Basically, you can expect it to handle scalars parameters correctly (int, void*, float, etc.), but it tends to get weird with other types (structs, arrays, complex types, etc). Lowering them correctly gets tricky in cases where you can't use "byval". The best resource is generally https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/TargetInfo.cpp .

[antonblanchard]

Thanks @eefriedman, that helps a lot. Unfortunately it looks like we lose signedness info before calling target code. We convert to LLVM types (type_of -> Type::uint_from_ty/Type::int_from_ty) which have no distinction between signed and unsigned, and pass these to target code.

[eefriedman]

Oh. Long-term, the ABI code obviously needs the Rust types as input, not LLVM types... but it's probably okay to just file an issue report and put in a FIXME here referring to it.

[alexcrichton]

Looking good to me, thanks @antonblanchard!

[antonblanchard]

Anything else that needs fixing?

[alexcrichton]

@bors: r+ 12aec07

Looks good to me!

[bors]

⌛ Testing commit 12aec07 with merge 28bf907...

[bors]

⛄ The build was interrupted to prioritize another pull request.