Some notes:

I tried bootstrapping Clang on 32-bit x86 with -Os and different values for MaxStoresPerMemcpyOptSize and MaxStoresPerMemmoveOptSize

Size MaxStoresPerMemcpyOptSize
67964194 1
6800925 2
68029730 3
68037922 4

(4 is the default)

So it seems setting it to 1 would be a size win.

But there might be more going on here. Consider the following example:

#include <string.h>
void f(char *dst, const char *src) {
memcpy(dst, src, 9);
}

At -O2 we will lower it with loads and stores:
00000000 :
0: 8b 44 24 04 mov 0x4(%esp),%eax
4: 8b 4c 24 08 mov 0x8(%esp),%ecx
8: 8a 51 08 mov 0x8(%ecx),%dl
b: 88 50 08 mov %dl,0x8(%eax)
e: f2 0f 10 01 movsd (%ecx),%xmm0
12: f2 0f 11 00 movsd %xmm0,(%eax)
16: c3 ret

At -Os, with the threshold set to 1, we make the call, and save one byte:

00000000 :
0: 83 ec 10 sub $0x10,%esp
3: 6a 09 push $0x9
5: ff 74 24 1c pushl 0x1c(%esp)
9: ff 74 24 1c pushl 0x1c(%esp)
d: e8 fc ff ff ff call e <f+0xe>
12: 83 c4 1c add $0x1c,%esp
15: c3 ret

However, if dst and src in the source were "int" instead of "char", we'd use rep;movs to copy two 4-byte words, and do one 1-byte move afterwards, causing much larger code:

00000000 :
0: 57 push %edi
1: 56 push %esi
2: 8b 44 24 0c mov 0xc(%esp),%eax
6: 8b 54 24 10 mov 0x10(%esp),%edx
a: b9 02 00 00 00 mov $0x2,%ecx
f: 89 c7 mov %eax,%edi
11: 89 d6 mov %edx,%esi
13: f3 a5 rep movsl %ds:(%esi),%es:(%edi)
15: 8a 4a 08 mov 0x8(%edx),%cl
18: 88 48 08 mov %cl,0x8(%eax)
1b: 5e pop %esi
1c: 5f pop %edi
1d: c3 ret

The rep;movs lowering comes from X86SelectionDAGInfo::EmitTargetCodeForMemcpy. If we were to just 1-byte rep;movs instead, the code would be:

00000000 :
0: 57 push %edi
1: 56 push %esi
2: 8b 7c 24 0c mov 0xc(%esp),%edi
6: 8b 74 24 10 mov 0x10(%esp),%esi
a: b9 09 00 00 00 mov $0x9,%ecx
f: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
11: 5e pop %esi
12: 5f pop %edi
13: c3 ret

Which is the smallest yet.

Maybe at -Os we should try to avoid ending up with remaining bytes after rep;movs and instead work with a smaller type, or just make the library call. Perhaps doing this would be better than trying to lower MaxStoresPerMemcpyOptSize.

(Mostly notes to self)
CMake invocation:
$ CC=/work/llvm/build.release/bin/clang CXX=/work/llvm/build.release/bin/clang++ CFLAGS="-m32" CXXFLAGS="-m32" cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS_RELEASE="-Os" -DCMAKE_CXX_FLAGS_RELEASE="-Os" -GNinja ..

Needed to apply this patch to avoid crashing:

--- a/lib/Target/X86/X86SelectionDAGInfo.cpp
+++ b/lib/Target/X86/X86SelectionDAGInfo.cpp
@@ -241,6 +241,8 @@ SDValue X86SelectionDAGInfo::EmitTargetCodeForMemcpy(

unsigned UBytes = AVT.getSizeInBits() / 8;
unsigned CountVal = SizeVal / UBytes;

• if (!CountVal)
• return SDValue();
  SDValue Count = DAG.getIntPtrConstant(CountVal, dl);
  unsigned BytesLeft = SizeVal % UBytes;

Some measurements on a 32-bit Chrome build on Windows:

Threshold Size (chrome_child.dll)
4 50,785,280
2 50,761,728
1 50,719,232