BountySource campaign for gcc PR/91851

BountySource campaign for gcc PR/91851

[John Paul Adrian Glaubitz]

Hello!

For anyone who isn't aware of it yet, there is an ongoing BountySource campaign
for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that
it can be kept in gcc versions beyond version 11.

The campaign is currently at $3,290 and can be found at [2].

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
> [2] https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: BountySource campaign for gcc PR/91851

[Georg-Johann Lay]

John Paul Adrian Glaubitz schrieb:
> Hello!
> 
> For anyone who isn't aware of it yet, there is an ongoing BountySource campaign
> for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that
> it can be kept in gcc versions beyond version 11.

Hi, have the cc0 backends been deprecated?

I didn't follow the lists for some time...  At least neither v9 or v10
release notes caveats mention such deprecation, neither is there
respective PRs for the cc0 targets.

Johann

> The campaign is currently at $3,290 and can be found at [2].
> 
> Thanks,
> Adrian
> 
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
>> [2] https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> 

Re: BountySource campaign for gcc PR/91851

[Peter Bergner]

On 10/30/19 2:31 PM, Georg-Johann Lay wrote:
> Hi, have the cc0 backends been deprecated?
> 
> I didn't follow the lists for some time...  At least neither v9 or v10
> release notes caveats mention such deprecation, neither is there
> respective PRs for the cc0 targets.

https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

Peter

Re: BountySource campaign for gcc PR/91851

[Georg-Johann Lay]

Peter Bergner schrieb:
> On 10/30/19 2:31 PM, Georg-Johann Lay wrote:
>> Hi, have the cc0 backends been deprecated?
>>
>> I didn't follow the lists for some time...  At least neither v9 or v10
>> release notes caveats mention such deprecation, neither is there
>> respective PRs for the cc0 targets.
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
> 
> Peter

Ah, thanks.

So finally, the time has come to move to clang/llvm ?

Johann

Re: BountySource campaign for gcc PR/91851

[John Paul Adrian Glaubitz]

On 10/31/19 10:00 PM, Georg-Johann Lay wrote:
>>> I didn't follow the lists for some time...  At least neither v9 or v10
>>> release notes caveats mention such deprecation, neither is there
>>> respective PRs for the cc0 targets.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
>>
>> Peter
> 
> Ah, thanks.
> 
> So finally, the time has come to move to clang/llvm ?

Not quite. Motorola 68k is currently not officially supported by LLVM/Clang.

There is a port that is half-finished though [1] and there is also one guy from
Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I
have not been able to contact him though as his university address bounces.
I would love to see the code that was written there.

I have also played around with Rust on m68k based on the LLVM code on [1], but
it doesn't really work yet. I think finishing LLVM for m68k would be another
idea for a Bountysource campaign.

Adrian

> [1] https://github.com/M680x0/M680x0-llvm/
> [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902
> [3] https://github.com/glaubitz/rust/tree/m68k-linux

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: BountySource campaign for gcc PR/91851

[Georg-Johann Lay]

John Paul Adrian Glaubitz schrieb:
> On 10/31/19 10:00 PM, Georg-Johann Lay wrote:
>>>> I didn't follow the lists for some time...  At least neither v9 or v10
>>>> release notes caveats mention such deprecation, neither is there
>>>> respective PRs for the cc0 targets.
>>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
>>>
>>> Peter
>> Ah, thanks.
>>
>> So finally, the time has come to move to clang/llvm ?
> 
> Not quite. Motorola 68k is currently not officially supported by LLVM/Clang.

For AVR -- an other port affected by cc0 removal -- there is a 
LLVM/Clang port.  It' not as mature as GCC's avr port, but what counts 
in the end is support / responsiveness from the community and an 
openness for the requirements of deeply embedded targets.  I had gcc 
patches rejected by global maintainers (just a no-op hook for other 
targets) because it appeared they didn't even understand what the patch 
is about (and kept proposing alternative "solutions" that totally missed 
the point).

And code quality is deteriorating from version to version.  Whatever you 
do in the backend to mitigate it, there's always global changes that 
shreds any improvements...

Btw, does GCC support clobbering registers in branches (or 
cbranch<mode>4 for that matter)?  This requirement would come up when 
transitioning avr to cc_mode because cbranches would live post reload.

Johann


> There is a port that is half-finished though [1] and there is also one guy from
> Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I
> have not been able to contact him though as his university address bounces.
> I would love to see the code that was written there.
> 
> I have also played around with Rust on m68k based on the LLVM code on [1], but
> it doesn't really work yet. I think finishing LLVM for m68k would be another
> idea for a Bountysource campaign.
> 
> Adrian
> 
>> [1] https://github.com/M680x0/M680x0-llvm/
>> [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902
>> [3] https://github.com/glaubitz/rust/tree/m68k-linux

Re: BountySource campaign for gcc PR/91851

[Segher Boessenkool]

On Thu, Oct 31, 2019 at 11:46:27PM +0100, Georg-Johann Lay wrote:
> For AVR -- an other port affected by cc0 removal -- there is a 
> LLVM/Clang port.  It' not as mature as GCC's avr port, but what counts 
> in the end is support / responsiveness from the community and an 
> openness for the requirements of deeply embedded targets.

And you think you find that less in GCC?  Huh.

> I had gcc 
> patches rejected by global maintainers (just a no-op hook for other 
> targets) because it appeared they didn't even understand what the patch 
> is about (and kept proposing alternative "solutions" that totally missed 
> the point).

Please point me to that.  In private mail, if you prefer.

> And code quality is deteriorating from version to version.  Whatever you 
> do in the backend to mitigate it, there's always global changes that 
> shreds any improvements...

I don't see that.  Things that aren't maintained and have no good tripwire
tests for code quality can (and will) degrade naturally, of course.  But
maintained targets do not normally have a hard time keeping up.

> Btw, does GCC support clobbering registers in branches (or 
> cbranch<mode>4 for that matter)?  This requirement would come up when 
> transitioning avr to cc_mode because cbranches would live post reload.

Of course.  You cannot have *reloads* on branches, that is all.


Segher

cc0 -> CCmode questions

[Georg-Johann Lay]

Segher Boessenkool schrieb:
>> Btw, does GCC support clobbering registers in branches (or 
>> cbranch<mode>4 for that matter)?  This requirement would come up when 
>> transitioning avr to cc_mode because cbranches would live post reload.
> 
> Of course.  You cannot have *reloads* on branches, that is all.
> 
> Segher

Does this also apply to input reloads?

Suppose cbranch with constraints like

"d,r"
"n,r"

for the operands to be compared, where d is a register class that
can be compared against immediate, but registers in r can't be
compared to n in general.

For a case #2 target (only ccmode clobbers before reload), reload might
generate an input reload for the constant in the cbranch.

So this is for bidden?

Johann

Re: cc0 -> CCmode questions

[Jeff Law]

On 11/2/19 9:51 AM, Georg-Johann Lay wrote:
> Segher Boessenkool schrieb:
>>> Btw, does GCC support clobbering registers in branches (or
>>> cbranch<mode>4 for that matter)?  This requirement would come up when
>>> transitioning avr to cc_mode because cbranches would live post reload.
>>
>> Of course.  You cannot have *reloads* on branches, that is all.
>>
>> Segher
> 
> Does this also apply to input reloads?
> 
> Suppose cbranch with constraints like
> 
> "d,r"
> "n,r"
> 
> for the operands to be compared, where d is a register class that
> can be compared against immediate, but registers in r can't be
> compared to n in general.
> 
> For a case #2 target (only ccmode clobbers before reload), reload might
> generate an input reload for the constant in the cbranch.
> 
> So this is for bidden?
This should work in the LRA world just fine.  The problems are with
output reloads, not input reloads.

With an output reload on a branch you have to emit the reload at the
target(s) of the branch as well as the fallthru path (if one exists).
In theory we could do this for simple branches, but for indirects it'd
be virtually impossible.


jeff

Re: cc0 -> CCmode questions

[Segher Boessenkool]

On Sat, Nov 02, 2019 at 10:14:15AM -0600, Jeff Law wrote:
> On 11/2/19 9:51 AM, Georg-Johann Lay wrote:
> > Segher Boessenkool schrieb:
> >>> Btw, does GCC support clobbering registers in branches (or
> >>> cbranch<mode>4 for that matter)?  This requirement would come up when
> >>> transitioning avr to cc_mode because cbranches would live post reload.
> >>
> >> Of course.  You cannot have *reloads* on branches, that is all.

Sigh.  *Output reloads*, sorry for dropping a crucial word here :-/

> > Does this also apply to input reloads?
>
> This should work in the LRA world just fine.  The problems are with
> output reloads, not input reloads.

In the old reload world as well.  Only output reloads are a problem.

> With an output reload on a branch you have to emit the reload at the
> target(s) of the branch as well as the fallthru path (if one exists).

Or you can do something *before* the branch, but that is different for
every case, and harder to do anyway.

If you insert the reloads at the jump target, you'll need to make a
separate predecessor of the jump target and insert the reload *there*,
if we aren't the only predecessor of that target.

> In theory we could do this for simple branches, but for indirects it'd
> be virtually impossible.

Yup.  Luckily most branches with outputs are not indirect branches.

I would love if this problem was fixed once and for all (I only care
about LRA here of course).


Segher