This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RS6000] Fix PR61098, Poor code setting count register
- From: Alan Modra <amodra at gmail dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 12 May 2014 09:09:23 +0930
- Subject: Re: [RS6000] Fix PR61098, Poor code setting count register
- Authentication-results: sourceware.org; auth=none
- References: <20140508014846 dot GA5162 at bubble dot grove dot modra dot org> <CAGWvnyme6a+QLSxXwzUOxWAHWTokxZCySua_+25hUzaEVYvgPA at mail dot gmail dot com> <20140509024054 dot GE5162 at bubble dot grove dot modra dot org> <CAGWvny=3+XuqiWtxhB4HSXDWHRZMpNkhioTVeEpEs9C4vMWRGg at mail dot gmail dot com> <20140511225316 dot GH5162 at bubble dot grove dot modra dot org>
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 <amodra@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