[PATCH] D53417: [Clang][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked 8 inline comments as done.
wuzish added inline comments.


================
Comment at: clang/lib/Sema/SemaOverload.cpp:3941
+      return ImplicitConversionSequence::Better;
+  }
+
----------------
hubert.reinterpretcast wrote:
> This seems to duplicate the bug described here in https://bugs.llvm.org/show_bug.cgi?id=39361.
> ```
> typedef unsigned int GccType __attribute__((__vector_size__(16)));
> typedef __vector unsigned int AltiVecType;
> 
> typedef float GccOtherType __attribute__((__vector_size__(16)));
> 
> char *f(GccOtherType, int);
> template <typename T> int f(AltiVecType, T);
> template <typename T> int g(AltiVecType, T);
> char *g(GccOtherType, int);
> 
> bool zip(GccType v) { return f(v, 0) == g(v, 0); }
> ```
Thank you for the good case. I will fix it.

But the https://bugs.llvm.org/show_bug.cgi?id=39361 is not the same reason but similar. We can propose another patch to do this. I think the essential reason is that code as blow has not considered `ImplicitConversionSequence::Worse` so that outside caller goes into path to choose a non-template candidate first.


```
if (S.getLangOpts().MSVCCompat && SCS1.Second == ICK_Integral_Conversion &&
      SCS2.Second == ICK_Floating_Integral &&
      S.Context.getTypeSize(SCS1.getFromType()) ==
          S.Context.getTypeSize(SCS1.getToType(2)))
    return ImplicitConversionSequence::Better;
```


================
Comment at: clang/test/Sema/altivec-generic-overload.c:3
+
+typedef signed char __v4sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v4uc __attribute__((__vector_size__(16)));
----------------
hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > `__v4sc` is suspicious. The most consistent naming I have seen is `v16i8`, `v16u8`, `v8i16`, ...
> > > Do we need the double underscores?
> > > 
> > Because it's generic gcc vector type instead of altivec type so I choose the naming style.
> The naming style from `clang/lib/Headers/avxintrin.h` would still say that the `__v4sc` here should be `__v16qi`.
On, you mean the num. Yes, that should not be '4'. 


Repository:
  rC Clang

https://reviews.llvm.org/D53417