Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sparc64: passing structures with floats in registers should use floating point registers #57103

Open
karcherm opened this issue Dec 24, 2018 · 7 comments
Labels
C-bug Category: This is a bug. O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@karcherm
Copy link
Contributor

librustc_target/abi/call/sparc64.rs passes structures as Uniform, which get allocated to stack or "promoted" to integer registers by LLVM. According to the SPARC v9 64 Bit ABI definition in the SPARC Compliance Definition, floating point members should be promoted into floating point registers instead of integer registers, see page 47 in SCD 2.4.1. This also affects returning of structures, and makes run-pass/structs-enums/struct-return.rs fail. gcc returns the members of struct Floats in %d0, %o1 and %d4, whereas Rust expects the members to be in %o0, %o1 and %o2.

I guess we need to create a CastTarget that contains a mixture of Int and Float registers in the prefix with an empty tail. As structures with at most 256 bits (8 * 32 bits) can be returned in registers, the eight class items in the prefix are enough. I expect that the structures needs to be flattened, so a structure containing a structure containing a float also has the float value passed in a floating point register.

Unaligned Floats and Doubles (with __attribute__((packed))) end up being put in integer registers by gcc and clang, whereas "accidently" aligned floating point members get passed in integer registers by gcc and floating point registers by clang:

// Structure without "packed" declaration
struct str1 {
  float f;  // passed in %f0
  int i;    // passed in least-significant half of %o0
};

// Structure that gets misalignment due to packed declaration
struct str2 {
  short s;  // passed in bits 48..63 of %o0
  float f;  // passed in bits 16..47 of %o0 (due to misalignment)
} __attribute__((packed));

// Layout exactly as str1, but has alignof() 1. Different behaviour between gcc 8.2 and clang 7.0
struct str3 {
  float f;  // passed in most-significant half of %o0 (gcc) or in %f0 (clang)
  int i;    // passed in least-significant half of %o0
} __attribute__((packed));
@nagisa nagisa added O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Dec 24, 2018
@nagisa
Copy link
Member

nagisa commented Dec 24, 2018

Unaligned Floats and Doubles (with attribute((packed))) end up being put in integer registers by gcc and clang, whereas "accidently" aligned floating point members get passed in integer registers by gcc and floating point registers by clang:

I suspect that the specification does not really specify anything for this specific scenario. In that case, please fill/find a bug against clang/gcc about this and reference it here. This seems like an unfortunate discrepancy to deal with for all parties involved.

@karcherm
Copy link
Contributor Author

I suspect that the specification does not really specify anything for this specific scenario. In that case, please fill/find a bug against clang/gcc about this and reference it here. This seems like an unfortunate discrepancy to deal with for all parties involved.

You are right. Alignment overrides and especially unaligned variables are not covered by vendor specification, so gcc/clang need to get to an agreement by themselves. I will file bugs.

It would still be great for rust to be compatible regarding non-packed structs like str1.

@karcherm
Copy link
Contributor Author

karcherm commented Dec 25, 2018

@nagisa
Copy link
Member

nagisa commented Dec 25, 2018

I can fill a clang bug for you if you want.

@karcherm
Copy link
Contributor Author

@nagiso: Yes, please go ahead. You should be able to copy/paste the contents of the GCC report.

@nagisa
Copy link
Member

nagisa commented Dec 25, 2018

clang bug #40153

@steveklabnik
Copy link
Member

Triage: no movement whatsoever on the clang bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants