[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[f.mach4 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

Max <f.mach4 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |f.mach4 at gmail dot com

--- Comment #2 from Max <f.mach4 at gmail dot com> ---
I am interested in working on this, because it would be a big shame to see AVR
support dropped from GCC. However, while I studied computer science at
university and of course have decent experience with the AVR platform, I do not
have a background in compilers nor have ever contributed to GCC before.

I have read some of the GCC internals manual and browsed around the source
tree, including gcc/config/avr, but I am still missing out on some foundational
understanding of how everything fits together inside GCC. 

Is there anyone more familiar with GCC internals and/or the AVR backend who I
would be able to consult or possibly work with on this?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #3 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Max from comment #2)
> Is there anyone more familiar with GCC internals and/or the AVR backend who
> I would be able to consult or possibly work with on this?

I think Jeff Law mentioned on the gcc-patches mailing list that he would be
willing to answer questions and assist anyone willing to work on MODE_CC
conversion.

So, I would ask on the list: https://gcc.gnu.org/mailman/listinfo/gcc-patches

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
See also https://gcc.gnu.org/pipermail/gcc/2020-April/thread.html#402 (for
details/current status, ask those involved).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[pipcet at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

pipcet at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pipcet at gmail dot com

--- Comment #5 from pipcet at gmail dot com ---
I'm interested in working on this.

There's some initial code at
https://github.com/gcc-mirror/gcc/compare/master...pipcet:avr-ccmode

I've followed the instructions at https://gcc.gnu.org/wiki/CC0Transition . I
believe AVR is an architecture which fits case #2 best: reload requires
arithmetic insns which clobber condition codes.

I decided to add explicit CC clobbers to the patterns for most insns rather
than relying on a post-reload splitter adding the CC clobbers, mostly because
that seemed simpler.

I've used a single REG_CC register in an 8-bit CCmode, representing all bits of
SREG except for the interrupt flag. (Once things are up and running, I plan to
investigate whether it's worth it to treat the carry flag and the transfer bit
separately).

The current state is that most code, particularly the gcc.c-torture/compile/
collection, appears to compile, but I haven't run the execution tests to figure
out what's working and what isn't.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[pipcet at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #6 from pipcet at gmail dot com ---
I've just pushed here

https://github.com/gcc-mirror/gcc/compare/master...pipcet:avr-ccmode-20200804?expand=1

the current state of my work as a series of git commits, sorted roughly from
large, mechanical, important changes to small, controversial, cosmetic ones.

I'm facing some problems:

1. It's hard to test. The test suite compiles okay, and I've tricked simulavr
into executing some test cases, but it's not as easy as simply running the test
suite, unless I'm missing something.

2. The assembler code often changes more than I thought it would. This makes
diffing it somewhat tedious.

3. Some peepholes need careful scrutiny. These are things like:

(define_peephole ; "*cpse.eq"
  [(set (cc0)
        (compare (match_operand:ALL1 1 "register_operand" "r,r")
                 (match_operand:ALL1 2 "reg_or_0_operand" "r,Y00")))
   (set (pc)
        (if_then_else (eq (cc0)
                          (const_int 0))
                      (label_ref (match_operand 0 "" ""))
                      (pc)))]
  "jump_over_one_insn_p (insn, operands[0])"
  "@
        cpse %1,%2
        cpse %1,__zero_reg__")

This replaces a flag-setting instruction plus a conditional branch with a
non-flag-setting conditional skip. Modifying only the obvious bits, this would
result in broken code which relied on the state of the CC flags after the
branch insn.

My current idea is to add a peephole2 pattern which adds a clobber of the CC
register to jump insns which don't need to preserve it, then require that extra
clobber in the above peephole. Not perfect, but it should catch most cases.

However, I'm unsure whether the approach of defining

(define_peephole2
  [(set (pc) (if_then_else (match_operator 0 "ordered_comparison_operator"
                                           [(reg:CC REG_CC) (const_int 0)])
                           (match_operand 1)
                           (match_operand 2)))]
  "peep2_reg_dead_p (1, gen_rtx_REG (CCmode, REG_CC))"
  [(parallel [(set (pc) (if_then_else (match_dup 0)
                                      (match_dup 1)
                                      (match_dup 2)))
              (clobber (reg:CC REG_CC))])])

is safe: if I'm looking at things correctly, peep2_reg_dead_p checks whether
the register is live in the instruction following the jump in the insn stream,
not the insn that the jump potentially goes to.

The good news is that I believe I've worked around the actual code quality
problems sufficiently for the patch set as it stands to be a good alternative
to dropping the AVR port.

I'd be really grateful for advice on how to test and improve this. Is there a
test suite somewhere that I've missed? Ideally, one that works with a free
simulator?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #7 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
> I'd be really grateful for advice on how to test and improve this. Is there a test suite somewhere that I've missed? Ideally, one that works with a free simulator?

Probably best to ask on the gcc-patches mailing list or one of the AVR forums
(avrfreaks maybe).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And please ping patches like
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552844.html if you don't
get a review.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

abebeos at lazaridis dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abebeos at lazaridis dot com

--- Comment #9 from abebeos at lazaridis dot com ---
Looking into this since a few days. All looks that B.S. statements seem valid:

https://gcc.gnu.org/pipermail/gcc/2020-April/000455.html

The bounty goal should be similar to "Convert m68k to not use cc0":

=> Convert avr to not use cc0 (thus it can be included to gcc11).

So, the requirements would be:

- must not use cc0
- keep generated code as much as possible identical (= avoid trouble and
follow-up work)
- use of MODE_CC constructs is optional

-

P.S.: It looks like previous work on this from "pipcet" got stuck, possibly
exactly due to the complexity that a larger one-chunk-change introduces,
especially when the resulting generated code changes much:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c6

So, if it's ok for the backers, reduce the scope of the bounty to "just get avr
into gcc11 and keep generated code as much as possible unchanged".

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to abebeos from comment #9)
> So, if it's ok for the backers, reduce the scope of the bounty to "just get
> avr into gcc11 and keep generated code as much as possible unchanged".

It would be gcc11 and beyond that, not just gcc11.

FWIW, I talked to multiple GCC developers and they confirmed that converting
the target to MODE_CC should be possible.

The main problem is apparently that the target hasn't been properly worked on
for a long time.

Also, be aware that there are others working on this such as:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551504.html

Good luck!

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #11 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #10)
[...]
> The main problem is apparently that the target hasn't been properly worked
> on for a long time.
[...]

Yes, this seems to result in this barrier:

=> missing stable development environment for the work on the avr backend
itself (build/test/simulate).

So this issue here splits into 3 major steps:

A) create a stable dev environment fro work on the avr backend
B) remove deprecated cc0 from avr backend (gcc11 requirement, main
issue&bounty), without necessarily using MODE_CC (similar to m68k)
C) (optional) convert code to MODE_CC

Seeing that the microchip custom version uses 5.x gcc and with different
dependencies than the original code, step A could already become a multi month
effort.

If anyone knows a "stable starting point" (for developing on the avr backend),
please point to it (ideally a public repo containing all).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #12 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Simulator: avrtest core simulator hosted on SourceForge as part of WinAVR.

Libc: avr-libc trunk hosted on nongnu.org. There are several patches not yet
integrated: recent xtiny devices, fixes in libm to adjust to the recent
double64 additions, and extensions for the build environment to handle the new
avr-gcc configure options for double multilib layout. Patches are pending for
some time; you'll have to resolve conflicts.

Binutils is vanilla from sourceware.org.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #13 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
FYI, avrtest is here:
https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #14 from abebeos at lazaridis dot com ---
(In reply to Georg-Johann Lay from comment #12)
> [...]you'll have to resolve conflicts.

(In reply to Georg-Johann Lay from comment #13)
> FYI, avrtest is here:
> https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/

Thanks a lot. 

I tested a dozen repos / scripts  with avr-gcc tool integration (which include
the tools/libs you mention, including avrtest and others), but always...
conflicts, even in the 5.x line.

Looks better today, though, after days of trouble, I'll invest two more days to
create a minimal setup, based on the xp gained.

Assuming that gcc does no automated regression tests currently for the avr
target?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #15 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I built the tools by hand so I knew what I had...

Dunno about gcc/buildbot policies concerning avr. As avr as a 3ary target, that
BE's quality is of no consideration when releasing the compiler. Again, I
added/ran tests by myself when working on the BE. However, test coverage is
low, and there are no performance tests. And there is no performance test suite
I know of that would work reasonably for AVR, or one that has been designed for
AVR/avr-gcc .

And be warned that the avr BE has many kludges, work-arounds and hacks. Some
are historical, but most of them work around shortcomings and flaws in the
middle-ends (nobody will fix middle-end issues that hamper a 3ary target).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #16 from abebeos at lazaridis dot com ---
I've updated the bounty, and you can follow the work here:

https://github.com/abebeos/avr-gnu

Whenever something relevant happens, I'll report it here.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #17 from abebeos at lazaridis dot com ---
Things look well, me being on 2 parallel solution paths:

a) using https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c6 as a foundation.

b) focusing more on a from-scratch work (cc0 elimination based on m68k
solution).

I case of a), what would be the (legal) process to contribute a patch (which is
based on code NOT YET contributed to the gcc project)? My understanding is that
the original author can e.g. place the code into the public-domain, see: 

https://gcc.gnu.org/contribute.html#legal

so I can modify and contribute it later using the standard procedures
(copyright assignment or again, placing the modified/extended code it into
public domain).


I'd like to avoid investing more time into a) and falling then into kind of a
copyright trap.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[pipcet at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #18 from pipcet at gmail dot com ---
Sorry for only getting back to this now.

I release all code on this branch into the public domain, if it helps at all.
I'm happy to add whatever legal attribution is needed for that.

I'm willing to help where I can, but please understand I've had to abandon this
due to an unfortunate combination of family and health issues. I'm sorry about
that.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #19 from abebeos at lazaridis dot com ---
pipcet, thank you for your quick response (both here and within email).

I think all here will agree that there's no need to apologize, as family/health
should always come first.

As for your work, if all goes fine, then I'll have validated your patch
tomorrow, so "The Last 2%" of the work can start. One or two more days and I
can make my local dev-system reproducible, so anyone can jump in to run the
tests and try to spot things.

I believe that it should be you (pipcet) that sends the final patch in (even if
I do modifications), but if you cannot do it, then "placing you initial patch
under public domain" should enable me to send a modified version in.

Now, going on, trying to keep the self-declared deadline (5th Dec. 2020).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #20 from abebeos at lazaridis dot com ---
Testsuite comparison on local dev system looks quite good:

https://github.com/abebeos/avr-gnu/issues/1

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[saaadhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

Senthil Kumar Selvaraj <saaadhu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |saaadhu at gcc dot gnu.org

--- Comment #21 from Senthil Kumar Selvaraj <saaadhu at gcc dot gnu.org> ---
FWIW, I was working on this as well some time in August, and had a semi working
implementation going. Pip's implementation generated better code on the few
benchmark workloads I compared, so I shelved my work
(https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I don't have the spare time now to start full fledged work on this, but I can
help with any issues you run into.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #22 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to abebeos from comment #20)
> Testsuite comparison on local dev system looks quite good:
> 
> https://github.com/abebeos/avr-gnu/issues/1

Just as a heads-up: Please keep in mind that submitting patches requires a
proper attribution and copyright assignment, see:

> https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #23 from abebeos at lazaridis dot com ---
(In reply to Senthil Kumar Selvaraj from comment #21)
> (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)

I can still do a test-run, to see if it produces less fails than pip's one.
Though it seems pip's work "last 2%" should be manageable. But in any case,
having a 2nd solution-path (based on your work) is nice, as I really want to
avoid to start from scratch (after those weeks of mostly integration work).

> I don't have the spare time now to start full fledged work on this, but I
> can help with any issues you run into.

Very nice, I can isolate the errors like:

=> "sorry, unimplemented: '-fzero-call-used-regs' not supported on this target"

so you folks can take a look with minimum effort. I'll file issues within the
github repo when I cannot solve something myself.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Amending / adjusting
https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
(the only place that somewhat "documents" how to setup AVR testing) is
appreciated.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #25 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #22)
[...]
> > https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

FSF has a fascinating way to make trivial things complicated. Largest-Scale
companies do such kind of legal stuff with one-click.

In any way, thank you for pointing to the official legal doc (I was looking for
in #comment17)

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #26 from abebeos at lazaridis dot com ---
(In reply to Richard Biener from comment #24)
> Amending / adjusting
> https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
> (the only place that somewhat "documents" how to setup AVR testing) is
> appreciated.

You'll find some instructions in https://github.com/abebeos/avr-gnu (should be
within the next days).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #27 from abebeos at lazaridis dot com ---
The "contrib/compare_tests" created a wrong delta.

"contrib/dg-cmp-results.sh seems to produce a more concise delta, and it shows
that...

==> ...we are down to essentially 6 issues:

PASS->FAIL: c-c++-common/zero-scratch-regs-10.c  -Wc++-compat  (test for excess
errors)
[...] (similar failure category)
NA->FAIL: gcc.dg/pr83480.c (internal compiler error)
PASS->FAIL: gcc.dg/pr83480.c (test for excess errors)
FAIL->PASS: gcc.dg/tree-ssa/pr92085-2.c (test for excess errors)
PASS->FAIL: gcc.target/avr/pr88253.c scan-assembler lds r\\d+,121
NA->FAIL: gcc.target/avr/torture/builtins-2-flash.c   -O1  (internal compiler
error)
[...] (similar failure category)

If i did not something very wrong with my testing, this means that those
failures should be nearly non-relevant (>100K tests pass).

I'll file tomorrow the remaining 5 issues with error-info here:

https://github.com/abebeos/avr-gnu/issues

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #28 from abebeos at lazaridis dot com ---
(In reply to Senthil Kumar Selvaraj from comment #21)
[...]
> I don't have the spare time now to start full fledged work on this, but I
> can help with any issues you run into.

Just a questions re your version, see
https://github.com/saaadhu/gcc-avr-cc0/issues/1.

As for my current main tests, there are 4 issues:
https://github.com/abebeos/avr-gnu/issues

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #29 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #23)
> (In reply to Senthil Kumar Selvaraj from comment #21)
> > (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)
> 
> I can still do a test-run, to see if it produces less fails
[...]

Test-Delta of your non-cc0 avr-backend is 0

> > I don't have the spare time now to start full fledged work on this, but I
> > can help with any issues you run into.

My understanding is that you have already contributor status here, so could you
make the patch available to the project?

I will today focus on publishing my test-setup, so that my test-results can be
peer-reviewed. Should be available within 12 hours, max 36.

If I did nothing wrong, then this means that your patch could go in. An
alternative would be to iron-out the last issues from pipcet's version
(possibly by using the constructs from your work).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to abebeos from comment #29)
> My understanding is that you have already contributor status here, so could
> you make the patch available to the project?

I don't think that's true, is it? I think Senthil Kumar needs to complete the
paperwork with the FSF for the patches to be "available to the project". Tht
can be done by assigning copyright to the FSF or completing a disclaimer to
place the work in the public domain.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #31 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Jonathan Wakely from comment #30)
> I don't think that's true, is it? I think Senthil Kumar needs to complete
> the paperwork with the FSF for the patches to be "available to the project".
> Tht can be done by assigning copyright to the FSF or completing a disclaimer
> to place the work in the public domain.

The question will also be who will get to claim the bounty? If everyone
contributes something, it will be more difficult to determine who gets what.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #32 from abebeos at lazaridis dot com ---
(In reply to Jonathan Wakely from comment #30)
> (In reply to abebeos from comment #29)
> > My understanding is that you have already contributor status here, so could
> > you make the patch available to the project?
> 
> I don't think that's true, is it? I think Senthil Kumar
[...]

See:

https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b81733335d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #33 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #31)
[...]
> The question will also be who will get to claim the bounty? If everyone
> contributes something, it will be more difficult to determine who gets what.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c11 and

It is essentially not one bounty, but 2 or even 3, that's why I asked for the
increase of the bounty, see "Update" section:

https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases.

But!!!

We're risking to interrupt my perfect flow with such stuff ("paperwork"
"bounty" etc.). I need my flow for 2 more days minimum.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #34 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #29)
[...]
> I will today focus on publishing my test-setup, so that my test-results can
> be peer-reviewed. Should be available within 12 hours, max 36.
[...]
https://github.com/abebeos/avr-gnu - drafty, you should await the next version
before trying. avrtest setup is missing.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #35 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> [...]
> > The main problem is apparently that the target hasn't been properly worked
> > on for a long time.
> [...]
> 
> Yes, this seems to result in this barrier:
> 
> => missing stable development environment for the work on the avr backend
> itself (build/test/simulate).
> 
> So this issue here splits into 3 major steps:
> 
> A) create a stable dev environment fro work on the avr backend
[...]

See https://github.com/abebeos/avr-gnu, should work as described.

My tests show:

=> pipcet's aborted non-cc0 backend results in 4 issues.
=> saaadhu's "shelved" non-cc0 backend results in 0 issues.

Tests should be easily reproducible.

We can "talk business" now, i don't need to focus anymore.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #36 from abebeos at lazaridis dot com ---
Created attachment 49686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49686&action=edit
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend

this should(!) be the final patch, derived from:

https://github.com/saaadhu/gcc-avr-cc0/commit/53b9401f0afe1f8cd679b982ecca1d3332ea2c37

(change to gcc/emit-rtl.c stripped, as it's already in the gcc repo).

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #37 from abebeos at lazaridis dot com ---
?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #38 from abebeos at lazaridis dot com ---
Can someone please ping gcc-patches (me having troubles setting up email alias
on gmail, don't want to use my main email)

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #39 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to abebeos from comment #38)
> Can someone please ping gcc-patches (me having troubles setting up email
> alias on gmail, don't want to use my main email)

I'm not sure what you are trying to achieve.

There are guidelines for submitting patches which include signing the FSF
copyright assignment using your full name and a proper email address.

It's not possible to merge patches anonymously and it's also not possible to
claim a bounty for the work contributed by a third party.

An example for the proper process for submission of such a patch can be found
here:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #40 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #39)
> (In reply to abebeos from comment #38)
> > Can someone please ping gcc-patches (me having troubles setting up email
> > alias on gmail, don't want to use my main email)
> 
> I'm not sure what you are trying to achieve.

Naturally, at this point, that someone verifies my results (I made this as
simple as a few cli commands). 

> There are guidelines for submitting patches which include signing the FSF
> copyright assignment using your full name and a proper email address.

No need for full-name in public (FSF accepts even pseudonyms), no need to sign
anything just to get a technical feedback ("review"). We are now in "review"
state.

> It's not possible to merge patches anonymously and it's also not possible to
> claim a bounty for the work contributed by a third party.

I spend nearly a full-(over)-time month to achieve a result, fighting through
incomplete/inconsistent/missing documentation and "dark land", providing
finally the necessary (mostly) integration work. If I reuse existing code
instead of writing from scratch, well, I think that's the original authors
decision how to handle this.

But please stop talking like I did nothing, that's simply rude.

> An example for the proper process for submission of such a patch can be
> found here:
> 
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559698.html

Too much talk for my taste. Test-suites talk better.

And if i need a lawyer to just be able to claim a bounty, well...

The thing is: can someone please verify the test-results?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #41 from abebeos at lazaridis dot com ---
[RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0
conversion)

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561427.html

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #42 from abebeos at lazaridis dot com ---
from Dimitar Dimitrov dimitar@dinux.eu within
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html

> I tested the trees you have given with my own AVR test setup [1]. I confirm 
> your results:
>  - saaadhu's tree does not introduce any regressions.
>  - pipcet's tree has 142 gcc and 299 g++ regressions (although many of them
>    are duplicates, e.g. same test case with different optimization levels).
>
> [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #43 from abebeos at lazaridis dot com ---
The patch is now (after further validation zero regressions within gcc/g++
testsuite in 2 different test-setups) "out there":

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561718.html

My understanding of the process tells me:

- the relevant maintainers decide about the patch.
- if merged, then this issue can be closed. then...
- the bounty backers (and only they) decide about the claims to the bounty.

https://github.com/bountysource/core/wiki/Frequently-Asked-Questions#how-are-claims-processed

38 backers - it looks quite impossible for one malicious claimant to cheat the
system.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

abebeos at lazaridis dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chertykov at gmail dot com

--- Comment #44 from abebeos at lazaridis dot com ---
added Denis Chertykov <chertykov@gmail.com> (listed avr maintainer) to cc

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #45 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #40)
> (In reply to John Paul Adrian Glaubitz from comment #39)
[...]
> I spend nearly a full-(over)-time month to achieve a result, fighting
> through incomplete/inconsistent/missing documentation and "dark land",
> providing finally the necessary (mostly) integration work. If I reuse
> existing code instead of writing from scratch, well, I think that's the
> original authors decision how to handle this.
> 
> But please stop talking like I did nothing, that's simply rude.
[...]

Folks!

Take a look at this message from John Paul Adrian Glaubitz:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561706.html

Now, please tell me:

- Does my management/integration work on this issue exist?
- Do I exist?

Rhetorical questions, I'm out for now, see:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561762.html

.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #46 from abebeos at lazaridis dot com ---
This addresses the Bounty-Backers:

https://github.com/abebeos/avr-gnu/blob/master/doc/README.md

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #47 from abebeos at lazaridis dot com ---
Relevant news:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562114.html

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[saaadhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #48 from Senthil Kumar Selvaraj <saaadhu at gcc dot gnu.org> ---
Submitted https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html,
which addresses comments made when the work-in-progress version was submitted.
There are no regression failures (save for some tests that fail because of code
size increase) on atmega128, atxmega128a3, attiny40 and atmega8. 

Follow up patch
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563779.html improves
code size regressions. More patches along the way - fixing some define_splits,
and adding CC_CZN and CC_ZN modes, along with enabling the cmpelim pass.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[saaadhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

Senthil Kumar Selvaraj <saaadhu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #49 from Senthil Kumar Selvaraj <saaadhu at gcc dot gnu.org> ---
Both the above patches (rebased against latest master) are now committed.

See https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html and
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569253.html.

There's more work to be done to improve code gen (as described in
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html), and I
intend to work on those items in my spare time.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #50 from abebeos at lazaridis dot com ---
Great!

It looks that bountysource does not allow to split a bounty.

Any suggestions on how to process this further?

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #51 from abebeos at lazaridis dot com ---
@Senthil, can you please provide the links to the commits? I was unable to
locate them.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #52 from abebeos at lazaridis dot com ---
All good, found it:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3ba781d3b5c8efadb60866c9743b657e8f0eb222

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[shiftee at posteo dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

Mark O'Donovan <shiftee at posteo dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shiftee at posteo dot net

--- Comment #53 from Mark O'Donovan <shiftee at posteo dot net> ---
As one of the BountySource contributors I received a notification about the
claim today by user saadhu. The claim looks legit and I will approve but it
could save lots of people having to validate the claim themselves if some
senior person could give it their blessing.
Thanks to all involved

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #54 from abebeos at lazaridis dot com ---
Bounty Claim:

Please not that "saaadhu"s patch was "shelved". I integrated a validation-setup
and tested several existent solutions, and identified during the "reuse
existent work" phase of my work "saaadhus" patch as the best one of two patches
(pipcet beeing the other one):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35

saaadhu continued the work at some point.

My overall effort is described in summary here:

https://github.com/abebeos/avr-gnu/blob/master/doc/README.md

The test-setup which led to the validation of saaadhu result is here:

https://github.com/abebeos/avr-gnu

Now, there is a strange tendency within this project to completely ignore my
work on this issue/bounty and my person, see e.g. here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45

Very sad, the very very basic rule of "correct attribution" (within OSS and
academia) seems to be non-existent. Not to talk about the behavior agains
"worker" (because I'm a simple worker in the context here, working to get some
income).

Additionally, saaadhu never replied to private email, even not to the last one:

"
Hi there!

It looks like bountysource has no functionality to split bounties, so we would
need to agree to a way of processing the split.

Are you ok with splitting the bounty 50/50?

One possible process:

- We tell the backers that we agreed
- I claim the bounty
- I get the amount granted on bountysource (this can take up to 2 weeks,
because of the veto period and the many backers),
- I file a bounty with 50% of the amount (around $3000) which you can claim
nearly immediately. This way we avoid the payout delays (sometimes a week or
more until money arrives on paypal), and all backers can see within a day that
we've done the split.

Please let me know if you have another suggestion.
"
correction: around $3500

-

The flow within this ticket here shows clearly that i contributed
significantly(!) to the fulfillment of this bounty, having invested multiple
weeks.

Backers may choose to ignore that fact.

Or the may not.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #55 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to abebeos from comment #54)
> Now, there is a strange tendency within this project to completely ignore my
> work on this issue/bounty and my person, see e.g. here:

You have no claim in this whole effort. You just tried to copy someone else's
work.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #56 from abebeos at lazaridis dot com ---
Oh, Mr. Glaubitz, thank you for your opinion.

It is you very personal choice to ignore "integration work" and label "reuse of
existent results" as "copy". I assume this does not reflect on policies of your
employer (physik.fu-berlin.de), because academia would not work without reuse &
attribution.

Lets see what other backers have to say, my efforts are clearly documented.

Note to readers:

Mr. Glaubitz is the same person which completely(!) ignored all my efforts
subjecting this issue, e.g. talking like I do not exist
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45).

It is the same person who blocks(!) me on github projects, just for replying to
users asking for info.

He's a bit allergic to my individuality, I guess.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #57 from abebeos at lazaridis dot com ---
Just fascinating!

Bountysource violated its own processes, and payed out the bounty without
waiting for the votes.

See, even without a dispute, there is a 2 week voting period ("The bounty will
be paid out if all backers accept your claim or if no backers reject your claim
by May 15, 2021 4:41 PM (GMT)")

But it looks like some "manual intervention" just skipped the process, without
waiting for the votes of the main backers:

        Microchip       $5,000  
        nseidle         $500    
        per1234         $300    

And i was mostly interested in what those 3 had to say.

GCC, Bountysource, just be aware that there is one word for this:

Cheating.

Please fix this, if its just one of the bountysource-bugs.

The voice of the major backers needs to count.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #58 from abebeos at lazaridis dot com ---
Well, now I'm really really curious.

Does the gcc project have at least some(!) liberal qualities, or will
IT-fascism win?

Follow-up:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #59 from abebeos at lazaridis dot com ---
Oh my, what a mess:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #60 from abebeos at lazaridis dot com ---
Notable sub-message:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570039.html

And the final essence, from:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570044.html

"
GCC issue, GCC resources(!), GCC committers, GCC participants.

Be aware that each and every person which noticed the non-attribution and
the rigged vote, without intervening, does this:

=> Supporting IT-fascism, in the name of GCC/GNU.

Including you - whoever you are.
"

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #61 from abebeos at lazaridis dot com ---
Now, the headline would be:

"Physik FU-Berlin, Microchip, Google, RedHat, IBM and more to Support Abuse,
Discrimination and even 'IT-fascism' via/on GCC/GNU/FSF Project-Resources".

See, nobody cares, until a valid(!) headline gets some visibility.

But for now I'll stop here, as I don't want to open/activate accounts in order
to publish. And in the end, I would analyze GCC/GNU/FSF weaknesses and threads
without getting payed.

Just one last thing:

John Paul Adrian Glaubitz, you have attacked my professional reputation in
public, saying more or less that I claimed the bounty without having done any
work for it.

But the indisputable fact is that any person that declares "assessment,
validation, integration and general reuse of existent results" as "copying"
should simply stay away from OSS software.

And persons which abuse their (position of) power to brute-force violate voting
procedures (or to not intervene), are just some (more or less worse) form  of
IT-fascists.

People like you should be kicked out immediately from OSS projects.

Well, at least in a perfect world.

Cu around, clowns.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #62 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:30a8771c0f5ddcbc329408c3bbf4f100b01acca9

commit r14-1688-g30a8771c0f5ddcbc329408c3bbf4f100b01acca9
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Sat Jun 10 21:47:53 2023 +0200

    target/109650: Fix wrong code after cc0 -> CCmode transition.

    This patch fixes a wrong-code bug in the wake of PR92729, the transition
that
    turned the AVR backend from cc0 to CCmode.  In cc0, the insn that uses cc0
like
    a conditional branch always follows the cc0 setter, which is no more the
case
    with CCmode where set and use of REG_CC might be in different basic blocks.

    This patch removes the machine-dependent reorg pass in avr_reorg entirely.

    It is replaced by a new, AVR specific mini-pass that runs prior to split2.
    Canonicalization of comparisons away from the "difficult" codes GT[U] and
LE[U]
    is now mostly performed by implementing TARGET_CANONICALIZE_COMPARISON.

    Moreover:

    * Text peephole conditions get "dead_or_set_regno_p (*, REG_CC)" as needed.

    * RTL peephole conditions get "peep2_regno_dead_p (*, REG_CC)" as needed.

    * Conditional branches no more clobber REG_CC.

    * insn output for compares looks ahead to determine the branch mode in use.
      This needs also "dead_or_set_regno_p (*, REG_CC)".

    * Add RTL peepholes for decrement-and-branch detection.

    * Some of the patterns like "*cmphi.zero-extend.0" lost their
      combine-ational part wit PR92729.  Restore them.

    Finally, it fixes some of the many indentation glitches left over from
PR92729.

    gcc/
            PR target/109650
            PR target/92729
            * config/avr/avr-passes.def (avr_pass_ifelse): Insert new pass.
            * config/avr/avr.cc (avr_pass_ifelse): New RTL pass.
            (avr_pass_data_ifelse): New pass_data for it.
            (make_avr_pass_ifelse, avr_redundant_compare, avr_cbranch_cost)
            (avr_canonicalize_comparison, avr_out_plus_set_ZN)
            (avr_out_cmp_ext): New functions.
            (compare_condtition): Make sure REG_CC dies in the branch insn.
            (avr_rtx_costs_1): Add computation of cbranch costs.
            (avr_adjust_insn_length) [ADJUST_LEN_ADD_SET_ZN,
ADJUST_LEN_CMP_ZEXT]:
            [ADJUST_LEN_CMP_SEXT]Handle them.
            (TARGET_CANONICALIZE_COMPARISON): New define.
            (avr_simplify_comparison_p, compare_diff_p, avr_compare_pattern)
            (avr_reorg_remove_redundant_compare, avr_reorg): Remove functions.
            (TARGET_MACHINE_DEPENDENT_REORG): Remove define.
            * config/avr/avr-protos.h (avr_simplify_comparison_p): Remove
proto.
            (make_avr_pass_ifelse, avr_out_plus_set_ZN, cc_reg_rtx)
            (avr_out_cmp_zext): New Protos
            * config/avr/avr.md (branch, difficult_branch): Don't split insns.
            (*cbranchhi.zero-extend.0", *cbranchhi.zero-extend.1")
            (*swapped_tst<mode>, *add.for.eqne.<mode>): New insns.
            (*cbranch<mode>4): Rename to cbranch<mode>4_insn.
            (define_peephole): Add dead_or_set_regno_p(insn,REG_CC) as needed.
            (define_deephole2): Add peep2_regno_dead_p(*,REG_CC) as needed.
            Add new RTL peepholes for decrement-and-branch and
*swapped_tst<mode>.
            Rework signtest-and-branch peepholes for *sbrx_branch<mode>.
            (adjust_len) [add_set_ZN, cmp_zext]: New.
            (QIPSI): New mode iterator.
            (ALLs1, ALLs2, ALLs4, ALLs234): New mode iterators.
            (gelt): New code iterator.
            (gelt_eqne): New code attribute.
            (rvbranch, *rvbranch, difficult_rvbranch, *difficult_rvbranch)
            (branch_unspec, *negated_tst<mode>, *reversed_tst<mode>)
            (*cmpqi_sign_extend): Remove insns.
            (define_c_enum "unspec") [UNSPEC_IDENTITY]: Remove.
            * config/avr/avr-dimode.md (cbranch<mode>4): Canonicalize
comparisons.
            * config/avr/predicates.md (scratch_or_d_register_operand): New.
            * config/avr/constraints.md (Yxx): New constraint.

    gcc/testsuite/
            PR target/109650
            * gcc.target/avr/torture/pr109650-1.c: New test.
            * gcc.target/avr/torture/pr109650-2.c: New test.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #63 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:6165b233ecc637efb5edcad8a34aae74b165a711

commit r13-7436-g6165b233ecc637efb5edcad8a34aae74b165a711
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Sat Jun 10 21:47:53 2023 +0200

    target/109650: Fix wrong code after cc0 -> CCmode transition.

    This patch fixes a wrong-code bug in the wake of PR92729, the transition
that
    turned the AVR backend from cc0 to CCmode.  In cc0, the insn that uses cc0
like
    a conditional branch always follows the cc0 setter, which is no more the
case
    with CCmode where set and use of REG_CC might be in different basic blocks.

    This patch removes the machine-dependent reorg pass in avr_reorg entirely.

    It is replaced by a new, AVR specific mini-pass that runs prior to split2.
    Canonicalization of comparisons away from the "difficult" codes GT[U] and
LE[U]
    is now mostly performed by implementing TARGET_CANONICALIZE_COMPARISON.

    Moreover:

    * Text peephole conditions get "dead_or_set_regno_p (*, REG_CC)" as needed.

    * RTL peephole conditions get "peep2_regno_dead_p (*, REG_CC)" as needed.

    * Conditional branches no more clobber REG_CC.

    * insn output for compares looks ahead to determine the branch mode in use.
      This needs also "dead_or_set_regno_p (*, REG_CC)".

    * Add RTL peepholes for decrement-and-branch detection.

    * Some of the patterns like "*cmphi.zero-extend.0" lost their
      combine-ational part wit PR92729.  Restore them.

    Finally, it fixes some of the many indentation glitches left over from
PR92729.

    gcc/
            PR target/109650
            PR target/92729
            Backport from 2023-05-10 master r14-1688.
            * config/avr/avr-passes.def (avr_pass_ifelse): Insert new pass.
            * config/avr/avr.cc (avr_pass_ifelse): New RTL pass.
            (avr_pass_data_ifelse): New pass_data for it.
            (make_avr_pass_ifelse, avr_redundant_compare, avr_cbranch_cost)
            (avr_canonicalize_comparison, avr_out_plus_set_ZN)
            (avr_out_cmp_ext): New functions.
            (compare_condtition): Make sure REG_CC dies in the branch insn.
            (avr_rtx_costs_1): Add computation of cbranch costs.
            (avr_adjust_insn_length) [ADJUST_LEN_ADD_SET_ZN,
ADJUST_LEN_CMP_ZEXT]:
            [ADJUST_LEN_CMP_SEXT]Handle them.
            (TARGET_CANONICALIZE_COMPARISON): New define.
            (avr_simplify_comparison_p, compare_diff_p, avr_compare_pattern)
            (avr_reorg_remove_redundant_compare, avr_reorg): Remove functions.
            (TARGET_MACHINE_DEPENDENT_REORG): Remove define.
            * config/avr/avr-protos.h (avr_simplify_comparison_p): Remove
proto.
            (make_avr_pass_ifelse, avr_out_plus_set_ZN, cc_reg_rtx)
            (avr_out_cmp_zext): New Protos
            * config/avr/avr.md (branch, difficult_branch): Don't split insns.
            (*cbranchhi.zero-extend.0", *cbranchhi.zero-extend.1")
            (*swapped_tst<mode>, *add.for.eqne.<mode>): New insns.
            (*cbranch<mode>4): Rename to cbranch<mode>4_insn.
            (define_peephole): Add dead_or_set_regno_p(insn,REG_CC) as needed.
            (define_deephole2): Add peep2_regno_dead_p(*,REG_CC) as needed.
            Add new RTL peepholes for decrement-and-branch and
*swapped_tst<mode>.
            Rework signtest-and-branch peepholes for *sbrx_branch<mode>.
            (adjust_len) [add_set_ZN, cmp_zext]: New.
            (QIPSI): New mode iterator.
            (ALLs1, ALLs2, ALLs4, ALLs234): New mode iterators.
            (gelt): New code iterator.
            (gelt_eqne): New code attribute.
            (rvbranch, *rvbranch, difficult_rvbranch, *difficult_rvbranch)
            (branch_unspec, *negated_tst<mode>, *reversed_tst<mode>)
            (*cmpqi_sign_extend): Remove insns.
            (define_c_enum "unspec") [UNSPEC_IDENTITY]: Remove.
            * config/avr/avr-dimode.md (cbranch<mode>4): Canonicalize
comparisons.
            * config/avr/predicates.md (scratch_or_d_register_operand): New.
            * config/avr/constraints.md (Yxx): New constraint.

    gcc/testsuite/
            PR target/109650
            Backport from 2023-05-10 master r14-1688.
            * gcc.target/avr/torture/pr109650-1.c: New test.
            * gcc.target/avr/torture/pr109650-2.c: New test.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #64 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:ee92dc2dae45acc79d4dc08ea31adf894831840a

commit r12-9691-gee92dc2dae45acc79d4dc08ea31adf894831840a
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Sat Jun 10 21:47:53 2023 +0200

    target/109650: Fix wrong code after cc0 -> CCmode transition.

    This patch fixes a wrong-code bug in the wake of PR92729, the transition
that
    turned the AVR backend from cc0 to CCmode.  In cc0, the insn that uses cc0
like
    a conditional branch always follows the cc0 setter, which is no more the
case
    with CCmode where set and use of REG_CC might be in different basic blocks.

    This patch removes the machine-dependent reorg pass in avr_reorg entirely.

    It is replaced by a new, AVR specific mini-pass that runs prior to split2.
    Canonicalization of comparisons away from the "difficult" codes GT[U] and
LE[U]
    is now mostly performed by implementing TARGET_CANONICALIZE_COMPARISON.

    Moreover:

    * Text peephole conditions get "dead_or_set_regno_p (*, REG_CC)" as needed.

    * RTL peephole conditions get "peep2_regno_dead_p (*, REG_CC)" as needed.

    * Conditional branches no more clobber REG_CC.

    * insn output for compares looks ahead to determine the branch mode in use.
      This needs also "dead_or_set_regno_p (*, REG_CC)".

    * Add RTL peepholes for decrement-and-branch detection.

    * Some of the patterns like "*cmphi.zero-extend.0" lost their
      combine-ational part wit PR92729.  Restore them.

    Finally, it fixes some of the many indentation glitches left over from
PR92729.

    gcc/
            PR target/109650
            PR target/92729
            Backport from 2023-05-10 master r14-1688.
            * config/avr/avr-passes.def (avr_pass_ifelse): Insert new pass.
            * config/avr/avr.cc (avr_pass_ifelse): New RTL pass.
            (avr_pass_data_ifelse): New pass_data for it.
            (make_avr_pass_ifelse, avr_redundant_compare, avr_cbranch_cost)
            (avr_canonicalize_comparison, avr_out_plus_set_ZN)
            (avr_out_cmp_ext): New functions.
            (compare_condtition): Make sure REG_CC dies in the branch insn.
            (avr_rtx_costs_1): Add computation of cbranch costs.
            (avr_adjust_insn_length) [ADJUST_LEN_ADD_SET_ZN,
ADJUST_LEN_CMP_ZEXT]:
            [ADJUST_LEN_CMP_SEXT]Handle them.
            (TARGET_CANONICALIZE_COMPARISON): New define.
            (avr_simplify_comparison_p, compare_diff_p, avr_compare_pattern)
            (avr_reorg_remove_redundant_compare, avr_reorg): Remove functions.
            (TARGET_MACHINE_DEPENDENT_REORG): Remove define.
            * config/avr/avr-protos.h (avr_simplify_comparison_p): Remove
proto.
            (make_avr_pass_ifelse, avr_out_plus_set_ZN, cc_reg_rtx)
            (avr_out_cmp_zext): New Protos
            * config/avr/avr.md (branch, difficult_branch): Don't split insns.
            (*cbranchhi.zero-extend.0", *cbranchhi.zero-extend.1")
            (*swapped_tst<mode>, *add.for.eqne.<mode>): New insns.
            (*cbranch<mode>4): Rename to cbranch<mode>4_insn.
            (define_peephole): Add dead_or_set_regno_p(insn,REG_CC) as needed.
            (define_deephole2): Add peep2_regno_dead_p(*,REG_CC) as needed.
            Add new RTL peepholes for decrement-and-branch and
*swapped_tst<mode>.
            Rework signtest-and-branch peepholes for *sbrx_branch<mode>.
            (adjust_len) [add_set_ZN, cmp_zext]: New.
            (QIPSI): New mode iterator.
            (ALLs1, ALLs2, ALLs4, ALLs234): New mode iterators.
            (gelt): New code iterator.
            (gelt_eqne): New code attribute.
            (rvbranch, *rvbranch, difficult_rvbranch, *difficult_rvbranch)
            (branch_unspec, *negated_tst<mode>, *reversed_tst<mode>)
            (*cmpqi_sign_extend): Remove insns.
            (define_c_enum "unspec") [UNSPEC_IDENTITY]: Remove.
            * config/avr/avr-dimode.md (cbranch<mode>4): Canonicalize
comparisons.
            * config/avr/predicates.md (scratch_or_d_register_operand): New.
            * config/avr/constraints.md (Yxx): New constraint.

    gcc/testsuite/
            PR target/109650
            Backport from 2023-05-10 master r14-1688.
            * gcc.target/avr/torture/pr109650-1.c: New test.
            * gcc.target/avr/torture/pr109650-2.c: New test.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #65 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:dae3456965064c9664c097c785ae9bf9fa203fa0

commit r14-9280-gdae3456965064c9664c097c785ae9bf9fa203fa0
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Sun Mar 3 13:01:24 2024 +0100

    AVR: ad target/92792 - Remove insn attribute "cc" and its (dead) uses.

    The backend has remains of cc0 condition code.  Unfortunately,
    all that information is useless with CCmode, and their use was
    removed with the removal of NOTICE_UPDATE_CC in PR92729 with
    r12-226 and r12-327.

    gcc/
            PR target/92729
            * config/avr/avr.md (define_attr "cc"): Remove.
            * config/avr/avr-protos.h (avr_out_plus): Remove pcc argument
            from prototype.
            * config/avr/avr.cc (avr_out_plus_1): Remove pcc argument and
            its uses.  Add insn argument.
            (avr_out_plus_symbol): Remove pcc argument and its uses.
            (avr_out_plus): Remove pcc argument and its uses.
            Adjust calls of avr_out_plus_symbol and avr_out_plus_1.
            (avr_out_round): Adjust call of avr_out_plus.