[libc++] inlining of char_trats<T>::eq() and friends wrt r217961

Following r217961, mclow asked me to verify that it didn’t interfere too badly with inlining of these calls on clang, and to send a summary here for the record.

I used the following (trivial) test:

#include

int main(int argc, char** argv) {
// Use values from argv to prevent the result from being
// constexpr evaluated.
if (std::char_traits::eq(argv[1][0], argv[1][1])) {
return 0;
} else {
return 1;
}
}

Level 2 and 3 both inline the call, before and after r217961:
$ clang -O2 …
$ objdump -d a.out
0000000000400670 :
400670: 48 8b 46 08 mov rax,QWORD PTR [rsi+0x8]
400674: 0f b6 48 01 movzx ecx,BYTE PTR [rax+0x1]
400678: 0f b6 00 movzx eax,BYTE PTR [rax]
40067b: 39 c8 cmp eax,ecx
40067d: 0f 95 c0 setne al
400680: 0f b6 c0 movzx eax,al
400683: c3 ret
400684: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
40068b: 00 00 00
40068e: 66 90 xchg ax,ax

Before r217961, -O0 and -O1 both inline:
$ clang -O1 …
$ objdump -d a.out

0000000000400670 :
400670: 48 8b 46 08 mov rax,QWORD PTR [rsi+0x8]
400674: 0f b6 48 01 movzx ecx,BYTE PTR [rax+0x1]
400678: 0f b6 00 movzx eax,BYTE PTR [rax]
40067b: 39 c8 cmp eax,ecx
40067d: 0f 95 c0 setne al
400680: 0f b6 c0 movzx eax,al
400683: c3 ret
400684: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
40068b: 00 00 00
40068e: 66 90 xchg ax,ax

After r217961, neither -O0 nor -O1 inline:
$ clang -O1 …
$ objdump -d a.out

4006bc: e8 0f 00 00 00 call 4006d0 <_ZNSt3__111char_traitsIcE2eqEcc>

Talked about this with mclow, and we’re not worried about it, since it still inlines for the optimized modes, and the patch does fix compatibility with GCC.