‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, February 16, 2020 3:10 PM, GT <tng...@protonmail.com> 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? > Jakub: Are there any specific changes you would like made to the patch? Bert.
