Sorry I missed this discussion until now, I have been out of the office
much of the last week.
On 2/16/20 2:10 PM, GT wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, February 14, 2020 5:09 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Feb 14, 2020 at 10:02:39PM +0000, GT wrote:
Function rs6000_simd_clone_adjust, even though it's body is empty,
cannot simply be removed. I tried it. It resulted in ICE. In my
view, leaving it empty is preferable to modifying other files
unrelated to rs6000.c in order to avoid having a function whose
body is empty.
So shouldn't the callback set target attribute (on definitions) to "vsx"?
I did consider doing something similar to aarch64_simd_clone_adjust. But the
reason
Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a
modified
function calling sequence for vector functions. PPC64 vector functions use the
existing
function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new
attribute
here, the function body ends up empty.
Have I missed something crucial?
I haven't seen anything in the patch that would only enable it for ELFv2,
The idea is that the vector functionality defined in the ABI is guaranteed only
on systems that implement the ELFv2 ABI. It's possible that the functionality
also
works on ELFv1 Big-Endian PPC64. I'll check if that's the case. If so, then the
ABI
will need modification.
and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
(haven't verified), powerpc64-linux or powerpc-linux certainly doesn't.
The last function in the patch, rs6000_simd_clone_usable, returns a value that
will
disable use of vector variants if TARGET_VSX is undefined.
And it is just fine to have the ABI for those pass/return vectors in VSX
registers too, after all, it won't be used if the vectorized caller isn't
TARGET_VSX,
Don't quite understand the comment here. Are you stating the possibility of
a system that has VSX hardware but does not define macro TARGET_VSX?
the definitions of the declare simd functions could be compiled
with different ISA options.
Do you mean the 'b' vs 'c' in the ABI's vector function name mangling?
And, if the ABI sais that the 'b' stuff assumes
certain ISA extensions, if the declare simd function definition is compiled
with e.g. -mno-vsx -mno-altivec, it would either not be able to get the
arguments/return values at all, or wouldn't benefit from the ISA guarantees
the ABI gives to it.
Not sure if you expect a response here.
BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is
unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c',
'd' and 'e') and then let the vectorized callers choose based on what ISA
options it is compiled with.
The reason 'c' was added to the ABI is this mailing list discussion:
https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html
As long as 'b' specifies that the VSX functionality is that specified in ISA
v2.07,
I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio?
No, I don't think that's the right call. We want to leverage ISA 3.0
instructionsin vector implementations when they are available, so we
need the 'c' ABI for that purpose. In future we are likely to add a
'd' ABI for a future processor if it adds more vector capability. So
emitting both and letting the vectorized callers choose, as Jakub
suggests, seems like the right way to go. This is true even if the
current implementations are identical (i.e., don't exploit any ISA
3.0 instructions).
Again, sorry for the tardy response!
Bill
Bert.
