On Mon, 2020-01-27 at 15:01 +0100, Hans-Peter Nilsson wrote:
> > From: Jeff Law
> > Date: Fri, 20 Sep 2019 17:38:38 +0200
>
> Hi. I'm not going to question
>
> > The first step in that process is to drop support for cc0.
>
> but could you please elaborate on...
>
> > [cc0 support in gcc
> From: Jeff Law
> Date: Fri, 20 Sep 2019 17:38:38 +0200
Hi. I'm not going to question
> The first step in that process is to drop support for cc0.
but could you please elaborate on...
> [cc0 support in gcc core]
> code is broken in various ways,
> particularly WRT exceptions.
...that last
Hi!
On Tue, Oct 29, 2019 at 01:34:15PM -0600, Jeff Law wrote:
> That needs to turn into a define_insn_and_split. The idea is the form
> above is what's seen prior to register allocation and reloading. After
> reloading we turn it into a form with an attached clobber. We achieve
> this by
> On Oct 30, 2019, at 2:24 PM, Jeff Law wrote:
>
> On 10/30/19 2:12 AM, Richard Biener wrote:
>> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
>>
>> I think the wiki has better examples. That said, I wonder how much can
>> be automated here, for example when just considering CCmode
On 10/30/19 2:12 AM, Richard Biener wrote:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> I think the wiki has better examples. That said, I wonder how much can
> be automated here, for example when just considering CCmode (m68k has
> setcc IIRC) then for example all define_insns like
>
On 10/30/19 11:57 AM, John Paul Adrian Glaubitz wrote:
> On 10/30/19 6:52 PM, Gunther Nikl wrote:
>> Richard Sandiford wrote:
>>> FWIW it's already possible to do the transform you mention with:
>>>
>>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>>
>>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM
On 10/30/19 11:52 AM, Gunther Nikl wrote:
> Richard Sandiford wrote:
>> FWIW it's already possible to do the transform you mention with:
>>
>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>
>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
>
> Since "reload_completed" is referenced,
On 10/30/19 6:52 PM, Gunther Nikl wrote:
> Richard Sandiford wrote:
>> FWIW it's already possible to do the transform you mention with:
>>
>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>
>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
>
> Since "reload_completed" is referenced,
Richard Sandiford wrote:
> FWIW it's already possible to do the transform you mention with:
>
> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>
> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
Since "reload_completed" is referenced, this is only about the CC0
conversion, right?
Richard Biener writes:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>>
>> On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
>> > Hello!
>> >
>> > We have raised $5000 to support anyone willing to work on this for the
>> > m68k target [1]. We really need the m68k to stay as it's
Hi Jeff!!
On 10/29/19 8:34 PM, Jeff Law wrote:
>> Any chance that the unfinished code can be shared? I'm looking for any
>> blueprints that can be used as a guidance for the work on the m68k
>> backend.
> I'm not sure it'd be all that useful. The v850 bits would be a better
> starting point.
On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
> > Hello!
> >
> > We have raised $5000 to support anyone willing to work on this for the
> > m68k target [1]. We really need the m68k to stay as it's essential to
> > be able to compile for
On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
> Hello!
>
> We have raised $5000 to support anyone willing to work on this for the
> m68k target [1]. We really need the m68k to stay as it's essential to
> be able to compile for Linux/m68k, NetBSD/m68k and AROS/m68k (a new
> and
Hello!
On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law wrote:
>So this message is serving as official notice that we are *deprecating*
>all cc0 support in gcc-10. We are not removing any code or targets at
>this time -- removals would happen during the gcc-11 cycle.
>
>
>avr
>cris
>h8300
On September 22, 2019 1:48:34 AM GMT+02:00, Segher Boessenkool
wrote:
>On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote:
>> On 9/21/19 2:48 PM, Paul Koning wrote:
>> >> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>> >> On 9/20/19 11:22 AM, Richard Biener wrote:
>> >> Now if someone did
On Fri, Sep 20, 2019 at 09:38:38AM -0600, Jeff Law wrote:
> this time -- removals would happen during the gcc-11 cycle.
Hi Jeff,
I'm concerned that if I don't reach this milestone for VAX, it'll mean
that future code review will require justifying some of the original
changes which is getting
On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote:
> On 9/21/19 2:48 PM, Paul Koning wrote:
> >> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
> >> On 9/20/19 11:22 AM, Richard Biener wrote:
> >> Now if someone did a variant #2 without the optimization bits (ie,
> >> adding appropriate
On 9/21/19 2:48 PM, Paul Koning wrote:
>
>
>> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>>
>> On 9/20/19 11:22 AM, Richard Biener wrote:
>>> ... It seems to be that for the goal to keep a target alive a
>>> variant #2 conversion (according to the wiki) should be closely
>>> mirror CC0
> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>
> On 9/20/19 11:22 AM, Richard Biener wrote:
>> ...
>> It seems to be that for the goal to keep a target alive a variant #2
>> conversion (according to the wiki) should be closely mirror CC0
>> behavior and thus should be easier to achieve and
On 9/20/19 11:22 AM, Richard Biener wrote:
> On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law
> wrote:
>> At the register allocation BOF during the Cauldron someone (I
>> forget who) raised the question of when/how do we get rid of
>> reload.
>>
>> The first step in that process is to drop
I think the m68k-*-uclinuxoldabi* and vax-*-vms* cases need to move up to
the top of that case statement (duplicating the "not supported" error), to
keep that error even in the --enable-obsolete case.
I see tile* targets are referenced in the diff context. They were
obsoleted in GCC 8 (and
On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law wrote:
>At the register allocation BOF during the Cauldron someone (I forget
>who) raised the question of when/how do we get rid of reload.
>
>The first step in that process is to drop support for cc0. cc0 is a
>horribly antiquated mechanism
At the register allocation BOF during the Cauldron someone (I forget
who) raised the question of when/how do we get rid of reload.
The first step in that process is to drop support for cc0. cc0 is a
horribly antiquated mechanism for describing how to handle condition
codes. It has numerous
23 matches
Mail list logo
