Prefer __vector over vector keyword for altivec use

[serge-sans-paille]

Summary

`vector' uses the keyword-and-predefine mode from gcc, while __vector is
reliably supported.

As a side effect, it also makes the code consistent in its usage of __vector.

[serge-sans-paille]

@hans : clang 10.0.0rc1 doesn't build on ppc64le in Fedora without that patch.

[hans]

It looks like the current code goes way back, to https://llvm.org/r39093 Do you know why it's started failing now?

Consistency is nice though, so I don't see any downside to this.

[serge-sans-paille]

Do you know why it's started failing now?

Not quite, probably a gcc update.

[hans]

In D74129#1861777, @serge-sans-paille wrote:

@hans : clang 10.0.0rc1 doesn't build on ppc64le in Fedora without that patch.

Cherry-picked to 10.x as 699e2a6c5551eacf10be7e64f579120954f55b10. Thanks!

clang/lib/Lex/Lexer.cpp

#ifdef __SSE2__
         }
         CurPtr += 16;
       }
 #elif __ALTIVEC__
       __vector unsigned char Slashes = {
         '/', '/', '/', '/',  '/', '/', '/', '/',
         '/', '/', '/', '/',  '/', '/', '/', '/'
       };
-      while (CurPtr+16 <= BufferEnd &&
-             !vec_any_eq(*(const vector unsigned char*)CurPtr, Slashes))
+      while (CurPtr + 16 <= BufferEnd &&
+             !vec_any_eq(*(const __vector unsigned char *)CurPtr, Slashes))
         CurPtr += 16;
 #else
       // Scan for '/' quickly.  Many block comments are very large.
       while (CurPtr[0] != '/' &&
              CurPtr[1] != '/' &&
              CurPtr[2] != '/' &&
              CurPtr[3] != '/' &&
              CurPtr+4 < BufferEnd) {