https://bugs.llvm.org/show_bug.cgi?id=39982
Bug ID: 39982
Summary: __attribute__((pcs("aapcs-vfp"))) is not consistent
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: srhi...@google.com
CC: kristof.be...@arm.com, llvm-bugs@lists.llvm.org,
peter.sm...@linaro.org, ties.st...@arm.com
This is from an internal Google bug, but really has to do with ARM backend
handling of aapcs-vfp. From that bug:
float __attribute__((pcs("aapcs-vfp"))) baz(float x, float y) {
return y;
}
struct S {
float f;
float d;
};
float __attribute__((pcs("aapcs-vfp"))) foo(S s) {
return s.d;
}
float __attribute__((pcs("aapcs"))) bar(S s) {
return s.d;
}
Compilation in hard-fp mode produces expected output (
https://godbolt.org/z/SdXIsN ):
baz(float, float):
vmov.f32 s0, s1
bx lr
foo(S):
vmov.f32 s0, s1
bx lr
bar(S):
mov r0, r1
bx lr
Compilation in soft-fp mode produces very strange output (
https://godbolt.org/z/HVVDtj ):
baz(float, float):
vmov.f32 s0, s1
bx lr
foo(S):
vmov s0, r1
bx lr
bar(S):
mov r0, r1
bx lr
It looks as if "foo" function uses hard-fp mode for result but soft-fp for
input.
Unfortunatelly vulkan uses pcs("aapcs-vfp") thus we couldn't just ignore that
issue (even if it looks as if currently vulkan does not suffer from that issue
- there very few functions with float arguments and they all are compiled
identically in hardfp and pcs("aapcs-vfp") modes).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs