Re: [cris-decc0 8/9] cris: Move trivially from cc0 to reg:CC model, removing most optimizations.

2020-01-28 Thread Hans-Peter Nilsson
> From: Segher Boessenkool 
> Date: Mon, 27 Jan 2020 23:52:21 +0100

> Hi!
> 
> On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> > I intend to put back as many as I find use for, of those
> > anonymous patterns in a controlled manner, with self-contained
> > test-cases proving their usability, rather than symmetry with
> > other instructions and similar addressing modes, which guided
> > the original introduction.  I've entered prX to track code
> > performance regressions related to this transition, with focus
> > on target-side causes and fixes; besides the function prologue
> > special-case, there were some checking presence of the bit-test
> > (btstq) instruction.
> 
> That's PR93372 (not X :-) ).

(Wow, someone read the log!)

Doh!  Thanks, will fix at next rebase.  (FWIW, I just added a
mail-send-hook to at least stop (and ask) me from sending email
with that kind of placeholder in the body. :)

> Do you have any estimate how much removing cc0 this way costs in
> performance (or code size, or any other metric)?

Not yet, by any quantifiable metrics, but I plan to do that once
I'm happy with compare-elim.c doing its job for the most glaring
cases.

Still, looking at differences to the cc0 version for libgcc, it
might even be an improvement due to better register allocation
(fewer saved registers and register moves and the like).  To
wit, that effect has a good chance of dominating over negative
fallout from missed compare-elimination opportunities and other
simplifications, just judging from initial observations.
Film at 11.

brgds, H-P


Re: [cris-decc0 8/9] cris: Move trivially from cc0 to reg:CC model, removing most optimizations.

2020-01-27 Thread Segher Boessenkool
Hi!

On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> I intend to put back as many as I find use for, of those
> anonymous patterns in a controlled manner, with self-contained
> test-cases proving their usability, rather than symmetry with
> other instructions and similar addressing modes, which guided
> the original introduction.  I've entered prX to track code
> performance regressions related to this transition, with focus
> on target-side causes and fixes; besides the function prologue
> special-case, there were some checking presence of the bit-test
> (btstq) instruction.

That's PR93372 (not X :-) ).

Do you have any estimate how much removing cc0 this way costs in
performance (or code size, or any other metric)?


Segher