http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854
--- Comment #2 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2012-07-04 17:17:22 UTC --- The problem with this is that there was a reason why I originally supported only a single constant pool reference per instruction: there needs to be an upper bound on the number of bytes consumed in the text section (code + literals) by a single insn, otherwise the "pool chunkify" mechanism doesn't work. As an obvious extreme example, if the asm were to refer to more than 4096 bytes of literals, it would be impossible to refer to them all using a single literal pool base pointer. As another obvious extreme example, if the asm *code* were to span more than 4096 bytes, it would be impossible to have even a single literal in the same chunk as the asm and thus be referenced from it (using the current chunkify algorithm). All this is less of an issue in 64-bit code since its much easier to address literals, but we still be should be correct for 31-bit on old machines too ... Why do the literals end up in the pool anyway in your example, as opposed to a register? They did with older compilers; this seems to have changed recently due to different IRA cost computations ... Maybe it would be better to prevent asm statements from generating pool references; it is likely that the asm will expect this to happen anyway?
