On Sun, Nov 24, 2019 at 08:55:37PM +0100, Bernd Schmidt wrote:
> On 11/24/19 8:43 PM, Segher Boessenkool wrote:
> > But. Allowing autoinc into jump insns means those jump insns may then
> > eventually need an output reload; it may just have been because of that?
>
> That's almost certainly the re
On 11/24/19 8:43 PM, Segher Boessenkool wrote:
> But. Allowing autoinc into jump insns means those jump insns may then
> eventually need an output reload; it may just have been because of that?
That's almost certainly the reasoning, but as I pointed out in my
original mail - reload is careful aro
On Sun, Nov 24, 2019 at 11:39:05AM -0600, Segher Boessenkool wrote:
> On Sun, Nov 24, 2019 at 03:19:49PM +0100, Bernd Schmidt wrote:
> > - /* This continue is deliberate. We do not want the uses of the
> > -jump put into reg_next_use because it is not considered safe to
> > -combine a
Hi!
On Sun, Nov 24, 2019 at 03:19:49PM +0100, Bernd Schmidt wrote:
> - /* This continue is deliberate. We do not want the uses of the
> - jump put into reg_next_use because it is not considered safe to
> - combine a preincrement with a jump. */
> - if (JUMP_P (insn))
> -
On 11/19/19 1:27 AM, Segher Boessenkool wrote:
> The combine parts are okay for trunk, if you keep an eye out :-)
Thanks, now committed. That leaves the auto-inc-dec part. Since we're
being adventurous, I've also bootstrapped and tested the following in
the meantime (on the gcc135 machine). This j
On Wed, Nov 13, 2019 at 02:21:01PM +0100, Bernd Schmidt wrote:
> After the m68k cc0 conversion, there is one code quality regression that
> I can see: we no longer generate autoinc addressing modes in
> comparisons. This is because the parts of the compiler that generate
> autoinc are unwilling to
