On Mon, May 12, 2014 at 08:23:16AM +0930, Alan Modra wrote: > On Sat, May 10, 2014 at 10:24:34PM -0400, David Edelsohn wrote: > > On Thu, May 8, 2014 at 10:40 PM, Alan Modra <amo...@gmail.com> wrote: > > > rs6000_emit_set_const ... always returns a non-zero result ... > > > > Can you help clarify the removal of the code that tests if the > > splitter failed? > > See above.
On thinking some more, let me retract the patch for the time being. While it's true that I was only removing dead code in the splitters, the question of why this code has become dead is worth looking into. I suspect a previous patch to rs6000_emit_set_const was wrong, and that we should in fact be failing before reload (but never after), when an expansion would take too many instructions. "Too many" being a sequence that is slower than loading a 64-bit constant from the TOC. We try to make that sort of tradeoff in rs6000_emit_move (see num_insn_constant call), but that is really too early. Some manipulations of code modify constants. I've seen cases where rs6000_emit_move decided to inline a constant, but later changes to the value meant the expansion was five instructions. -- Alan Modra Australia Development Lab, IBM
