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]

Have you checked that the sizes of all these types are correct? (They probably are, but it's worth double-checking.)

[antonblanchard]

Yes, just to confirm:

blkcnt_t 64
blksize_t 64
ino_t 64
nlink_t 64
off_t 64
time_t 64

[eefriedman]

This file has a lot of duplicated code from cabi_powerpc64.rs; it needs to be refactored.

[antonblanchard]

Thanks, will do

[mpe]

The only difference I see is in classify_ret_ty(), where the LE version is doing more complicated logic. But I suspect BE should probably also do that logic, in which case the two files would actually be identical?

[antonblanchard]

There are differences between the BE and LE ABI when it comes to returning aggregates. As an example:

struct foo {
    float a[8];
};

struct foo blah(struct foo x)
{
    return x;
}

On big endian we pass the return value via a pointer in r3:

blah:
    std 4, 0(3)
    std 5, 8(3)
    std 6, 16(3)
    std 7, 24(3)
    blr

On little endian we pass it via registers:

blah:
    blr

[mpe]

Oh sorry, I skimmed the ABI doc but obviously too lightly.

[eefriedman]

https://doc.rust-lang.org/nightly/std/primitive.usize.html#method.next_power_of_two ?

[eefriedman]

Err, wait, nevermind.

[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.

[mpe]

If I'm reading this right that's saying __NR_getrandom == 384, which is wrong. It's 359 for all powerpc kernels.

[antonblanchard]

Nice catch Michael, this looks like a bug introduced when powerpc32 support was added.

[mpe]

I'm guessing this needs to match _Unwind_Exception from clang? If so that looks right.

[alexcrichton]

It should be fine to not update this, these are largely just all a bunch of old directories that aren't used any more

[alexcrichton]

Could you switch this to target_pointer_width?

[alexcrichton]

Could you switch this to target_pointer_width as well?

[alexcrichton]

actually, similar to a bunch below as well

[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.