On Tue, Jun 8, 2021 at 2:32 PM Segher Boessenkool
wrote:
>
> On Tue, Jun 08, 2021 at 09:08:56AM +0200, Richard Biener wrote:
> > On Tue, Jun 8, 2021 at 4:10 AM Kewen.Lin via Gcc-patches
> > wrote:
> > > on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> > > > On Fri, Jun 04, 2021 at 10:57:51AM +0800
On Tue, Jun 08, 2021 at 09:08:56AM +0200, Richard Biener wrote:
> On Tue, Jun 8, 2021 at 4:10 AM Kewen.Lin via Gcc-patches
> wrote:
> > on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> > > On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
> > >> To find out those need fixin
On Tue, Jun 8, 2021 at 4:10 AM Kewen.Lin via Gcc-patches
wrote:
>
> Hi Segher,
>
> on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> > Hi!
> >
> > On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
> >> To find out those need fixing seems to be the critical part. It's
> >> n
Hi Segher,
on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
>> To find out those need fixing seems to be the critical part. It's
>> not hard to add one explicit "&&" to those that don't have it now, but
>> even wit
on 2021/6/7 下午3:12, Richard Biener wrote:
> On Fri, Jun 4, 2021 at 4:58 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi Segher,
>>
>> on 2021/6/3 下午5:18, Segher Boessenkool wrote:
>>> On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
On Thu, Jun 03, 2021 at 01:22:38PM +0800,
Hi!
On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
> To find out those need fixing seems to be the critical part. It's
> not hard to add one explicit "&&" to those that don't have it now, but
> even with further bootstrapped and regression tested I'm still not
> confid
On Fri, Jun 4, 2021 at 4:58 AM Kewen.Lin via Gcc-patches
wrote:
>
> Hi Segher,
>
> on 2021/6/3 下午5:18, Segher Boessenkool wrote:
> > On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
> >> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
> >> The whole point of requiring
on 2021/6/3 下午4:05, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richi/Richard/Jeff/Segher,
>>
>> Thanks for the comments!
>>
>> on 2021/6/3 锟斤拷锟斤拷7:52, Segher Boessenkool wrote:
>>> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
Richard Biener writes:
> So wh
Hi Segher,
on 2021/6/3 下午5:18, Segher Boessenkool wrote:
> On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
>> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
>> The whole point of requiring the split condition to start with && is so
>> it will become harder to mess t
On Thu, Jun 03, 2021 at 11:11:53AM -0600, Jeff Law wrote:
> On 6/3/2021 2:00 AM, Segher Boessenkool wrote:
> >The whole point of requiring the split condition to start with && is so
> >it will become harder to mess things up (it will make the gen* code a
> >tiny little bit simpler as well). And th
On Thu, Jun 03, 2021 at 04:25:44PM -0500, Segher Boessenkool wrote:
> If we could just start all over we could do it perfectly (but see
> second-system syndrome, heh). But we cannot. IMO we should especially
> avoid everything that uses new semantics for old syntax.
Agreed, that would be a night
On Thu, Jun 03, 2021 at 11:25:49AM +0100, Richard Sandiford wrote:
> We shouldn't just add "&&" to all define_insn_and_splits that currently
> lack them.
My previous post shows that this *already* is required.
> IMO it's not reasonable to ask Kewen to do that for all ports. So the
> process I su
On 6/3/2021 2:00 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
on 2021/6/3 上午7:52, Segher Boessenkool wrote:
- add a new "define_independent_insn_and_split" that has the
current semantics of define_insn_and_split. This should be
mechanic
Segher Boessenkool writes:
> On Thu, Jun 03, 2021 at 09:05:02AM +0100, Richard Sandiford via Gcc-patches
> wrote:
>> Right. Plus it creates less make-work. If we didn't have it, someone
>> would need to split the define_insn_and_splits that don't currently
>> use "&&", then later someone might
On Thu, Jun 03, 2021 at 09:05:02AM +0100, Richard Sandiford via Gcc-patches
wrote:
> Right. Plus it creates less make-work. If we didn't have it, someone
> would need to split the define_insn_and_splits that don't currently
> use "&&", then later someone might decide that the missing "&&" was a
On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
> The whole point of requiring the split condition to start with && is so
> it will become harder to mess things up (it will make the gen* code a
> tiny little bit simple
"Kewen.Lin" writes:
> Hi Richi/Richard/Jeff/Segher,
>
> Thanks for the comments!
>
> on 2021/6/3 锟斤拷锟斤拷7:52, Segher Boessenkool wrote:
>> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
>>> Richard Biener writes:
So what Richard suggests would be to disallow split conditio
Hi!
On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
> on 2021/6/3 上午7:52, Segher Boessenkool wrote:
> >> - add a new "define_independent_insn_and_split" that has the
> >> current semantics of define_insn_and_split. This should be
> >> mechanical.
> >
> > I'd rather not have that -
Hi Richi/Richard/Jeff/Segher,
Thanks for the comments!
on 2021/6/3 上午7:52, Segher Boessenkool wrote:
> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
>> Richard Biener writes:
>>> So what Richard suggests would be to disallow split conditions
>>> that do not start with "&& ",
On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
> Richard Biener writes:
> > So what Richard suggests would be to disallow split conditions
> > that do not start with "&& ", it's probably easy to do that as well
> > and look for build fails. That should catch all cases to look
On 6/2/2021 11:32 AM, Richard Sandiford wrote:
Richard Biener writes:
On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
on 2021/6/2 下午5:13, Richard Sandiford wrote:
"Kewen.Lin" writes:
Hi Richard,
on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
Kewen Lin writes:
Hi all,
define_insn
Richard Biener writes:
> On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
>>
>> on 2021/6/2 下午5:13, Richard Sandiford wrote:
>> > "Kewen.Lin" writes:
>> >> Hi Richard,
>> >>
>> >> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>> >>> Kewen Lin writes:
>> Hi all,
>>
>> define_in
On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
>
> on 2021/6/2 下午5:13, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> Hi Richard,
> >>
> >> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
> >>> Kewen Lin writes:
> Hi all,
>
> define_insn_and_split should avoid to use emp
on 2021/6/2 下午5:13, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>>> Kewen Lin writes:
Hi all,
define_insn_and_split should avoid to use empty split condition
if the condition for define_insn isn't empty,
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>> Kewen Lin writes:
>>> Hi all,
>>>
>>> define_insn_and_split should avoid to use empty split condition
>>> if the condition for define_insn isn't empty, otherwise it can
>>> sometimes result in unexpected con
Hi Richard,
on 2021/6/2 下午4:11, Richard Sandiford wrote:
> Kewen Lin writes:
>> Hi all,
>>
>> define_insn_and_split should avoid to use empty split condition
>> if the condition for define_insn isn't empty, otherwise it can
>> sometimes result in unexpected consequence, since the split
>> will al
Kewen Lin writes:
> Hi all,
>
> define_insn_and_split should avoid to use empty split condition
> if the condition for define_insn isn't empty, otherwise it can
> sometimes result in unexpected consequence, since the split
> will always be done even if the insn condition doesn't hold.
>
> To avoid
27 matches
Mail list logo
