Current implementation assumes that, each MachineConstantPoolValue takes up sizeof(MachineConstantPoolValue::Ty) bytes. For PowerPC, we want to lump all the constants with the same type as one MachineConstantPoolValue to save the cost that calculate the TOC entry for each const. So, we need to extend the MachineConstantPoolValue that break this assumption.
That is, transform:
addis 3, 2, .LCPI0_0@toc@ha lfd 0, .LCPI0_0@toc@l(3) addis 3, 2, .LCPI0_1@toc@ha lfd 1, .LCPI0_1@toc@l(3)
addis 3, 2, .LC0@toc@ha ld 3, .LC0@toc@l(3) lfd 0, 8(3) lfd 1, 0(3)
.LCPI0_0: .quad 0x40218d4fdf3b645a # double 8.7759999999999998 .LCPI0_1: .quad 0x49818d4fdf3b645a # double 1.2525525751187504E+46
.LCPI0_0: .quad 0x49818d4fdf3b645a # double 1.2525525751187504E+46 .quad 0x40218d4fdf3b645a # double 8.7759999999999998 .section ".note.GNU-stack","",@progbits .section .toc,"aw",@progbits .LC0: .tc .LCPI0_0[TC],.LCPI0_0
The more constants accessed, the more benefit we will have.
And this assumption also doesn't make sense to me as we have already provided mechanism for target to customize the constant pool with MachineConstantPoolValue. We shouldn't assume its size.