x86 codegen for long AddRec expansion could be improved

[efriedma-quic]

Bugzilla Link	2635
Version	trunk
OS	Linux
Attachments	Testcase (IL), Output from testcase (X86 assembly)
CC	@RKSimon,@sunfishcode

Extended Description

IL attached, generated from the following testcase:

int a(unsigned b) {
unsigned x1=0,x2=0,x3=0,x4=0,x5=0,x6=0,x7=0,x8=0,x9=0,x10=0,x11=0,x12=0,x13=0,x14=0,x15=0,x16=0,x17=0,i;
for (i = 0; i < b; i++) {x1+=x2+=x3+=x4+=x5+=x6+=x7+=x8+=x9+=x10+=x11+=x12+=x13+=x14+=x15+=x16+=x17+=1;}
return x1;
}

The issue is essentially that CodeGen ends up spilling the result of almost every single instruction; I haven't actually tried to hand-optimize it, but I think that if it actually did all the operations in the best order, and it was clever enough to remat the additions, it wouldn't have to spill anything.

[efriedma-quic]

Ah, wow, that's some sucky pass ordering; running the attached sample through opt -std-compile-opts reduces the number of x86 instructions generated by almost 90 instructions! Although, that doesn't really affect the bug as reported... CodeGen is still doing some pretty horrible stuff.

[sunfishcode]

Specifically, -reassociate makes a big difference. llc generates 25% fewer
instructions if -reassociate is run first.

[RKSimon]

Current Codegen: https://c.godbolt.org/z/8sq2jo