Probably inefficient code generation

[baremetaldude]

Bugzilla Link	9658
Version	trunk
OS	Linux

Extended Description

Working on my compiler(http://code.google.com/p/bamelg/) I found that sometimes LLVM generates TOO many movb's
...
movb $0, 209(%esp)
movb $0, 208(%esp)
movb $0, 207(%esp)
movb $0, 206(%esp)
movb $0, 205(%esp)
movb $0, 204(%esp)
movb $0, 203(%esp)
...

following each other. ( total of ~500Kb of compiled movbs! )

Tested with rev 129071.

1. llc -O=3 -march=x86 test.bc -O=3 -o test.s
2. see test.s line 287-4403 ( also 47497-84488 )

PS. Code from real app and I have no idea how to reduce bytecode file to repro this

[llvmbot]

where is test.bc ?

[baremetaldude]

test file ( app with stripped contents )

[llvmbot]

Can you please regenerate the bitcode with globals (functions and variables)
having names rather than being anonymous. Being anonymous makes them a pain
to work with. Thanks!

[baremetaldude]

I cannot attach new testcase (globals and functions with meaningful names, no
opt) due to upload limit so you can download it from here:

http://bamelg.googlecode.com/svn/trunk/LLVMAttachments/9658_1.7z

PS. I use VS to find movbs with following multiline regex pattern
"movb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb.\n:bmovb"
nix-like regex to find such places probably is:
"movb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.\n\smovb.*\n\smovb"

[baremetaldude]

I think constructions like
"store %xxx zeroinitializer, %xxx* %yyy"
not optimized properly. For large types it must be optimized to memcpy intrinsic. "rep movsd\movups loop\memcpy" perform slightly better than tons of movbs =)