On Fri, 2019-12-06 at 16:51 -0600, Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> > On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > > > explicitly, but it's got a R
On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > > explicitly, but it's got a R0_REGS class with only one said reg in it.
> > > So the default impl
Here's a revised version based on the feedback so far. Changes in v2:
- Don't move instructions that set or use allocatable hard registers.
- Check legitimate_combined_insn
- Check cannot_copy_insn_p when keeping the original insn in parallel
- Disable the pass if HAVE_cc0
I compared v1 and v2 in
On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> > On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> > >
> > > > > - sh (that's sh4-linux):
> > > > >
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c: In fu
On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> >
> > > > - sh (that's sh4-linux):
> > > >
> > > > /home/segher/src/kernel/net/ipv4/af_inet.c: In function
> > > > 'snmp_get_cpu_field':
> > > > /home/segher/src/kernel/net
On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
>
> > > - sh (that's sh4-linux):
> > >
> > > /home/segher/src/kernel/net/ipv4/af_inet.c: In function
> > > 'snmp_get_cpu_field':
> > > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: unable to find
> > > a register to spill
On Wed, Nov 27, 2019 at 09:29:27AM +0100, Richard Biener wrote:
> On Tue, Nov 26, 2019 at 2:42 AM Segher Boessenkool
> wrote:
> > combine actually *calculates* DU chains almost completely, it just throws
> > away most of that information (it wants to have LOG_LINKS, as it did ages
> > ago). The o
Richard Biener writes:
> On Tue, Nov 26, 2019 at 2:42 AM Segher Boessenkool
> wrote:
>>
>> On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
>> > Segher Boessenkool writes:
>> > > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
>> > >> Segher Boessenkool writ
On Tue, Nov 26, 2019 at 2:42 AM Segher Boessenkool
wrote:
>
> On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> > >> Segher Boessenkool writes:
> > >> > I am wondering the o
On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> > I am wondering the other way around :-) Is what you do for combine2
> >> > something that
Segher Boessenkool writes:
> Hi!
>
> On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > I am wondering the other way around :-) Is what you do for combine2
>> > something that would be more generally applicable/useful? That's what
>> > I'm tryi
On Mon, Nov 25, 2019 at 09:40:36PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > - i386 goes into an infinite loop compiling, or at least an hour or so...
> > Erm I forgot too record what it was compiling. I did attach a GDB... It
> > is something from lra_create_live_ranges.
Hi!
On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > I am wondering the other way around :-) Is what you do for combine2
> > something that would be more generally applicable/useful? That's what
> > I'm trying to find out :-)
> >
> > What combi
Segher Boessenkool writes:
> Hi!
>
> On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
>> Richard Sandiford writes:
>> > (It's 23:35 local time, so it's still just about stage 1. :-))
>>
>> Or actually, just under 1 day after end of stage 1. Oops.
>> Could have sworn stage 1 en
Segher Boessenkool writes:
> On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > It's not great if every pass invents its own version of some common
>> > infrastructure thing because that common one is not suitable.
>> >
>> > I.e., can this be fix
On 11/23/19 6:09 PM, Segher Boessenkool wrote:
On Sat, Nov 23, 2019 at 06:01:28PM -0500, Nicholas Krause wrote:
Please just CC to this conversation as I keep getting removed.
Everyone who was on Cc: for this thread still is. This is how email
works. If you want to see everything on the lis
On Sat, Nov 23, 2019 at 06:01:28PM -0500, Nicholas Krause wrote:
> Please just CC to this conversation as I keep getting removed.
Everyone who was on Cc: for this thread still is. This is how email
works. If you want to see everything on the list, subscribe to the
mailing list?
Segher
On 11/23/19 5:34 PM, Segher Boessenkool wrote:
Hi!
On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
Richard Sandiford writes:
(It's 23:35 local time, so it's still just about stage 1. :-))
Or actually, just under 1 day after end of stage 1. Oops.
Could have sworn stage
Hi!
On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > (It's 23:35 local time, so it's still just about stage 1. :-))
>
> Or actually, just under 1 day after end of stage 1. Oops.
> Could have sworn stage 1 ended on the 17th :-( Only realised
> I
On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > It's not great if every pass invents its own version of some common
> > infrastructure thing because that common one is not suitable.
> >
> > I.e., can this be fixed somehow? Maybe just by having a
On Thu, Nov 21, 2019 at 07:41:56PM +, Richard Sandiford wrote:
> Nicholas Krause writes:
> >> +/* The instructions we're combining, in program order. */
> >> +insn_info_rec *sequence[MAX_COMBINE_INSNS];
> > Can't we can this a vec in order to grow to lengths and just loop through
> >
Segher Boessenkool writes:
> On Wed, Nov 20, 2019 at 06:20:34PM +, Richard Sandiford wrote:
>> > Why don't you use DF for the DU chains?
>>
>> The problem with DF_DU_CHAIN is that it's quadratic in the worst case.
>
> Oh, wow.
>
>> fwprop.c gets around that by using the MD problem and having
Hi Nick,
Thanks for the comments.
Nicholas Krause writes:
>> Index: gcc/passes.def
>> ===
>> --- gcc/passes.def 2019-10-29 08:29:03.224443133 +
>> +++ gcc/passes.def 2019-11-17 23:15:31.200500531 +
>> @@ -437,7 +437,9 @@
On 11/17/19 6:35 PM, Richard Sandiford wrote:
(It's 23:35 local time, so it's still just about stage 1. :-))
While working on SVE, I've noticed several cases in which we fail
to combine instructions because the combined form would need to be
placed earlier in the instruction stream than the l
On Wed, Nov 20, 2019 at 06:20:34PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > So this would work if you had pseudos here, instead of the hard reg?
> > Because it is a hard reg it is the same number in both places, making it
> > hard to move.
>
> Yeah, probably. But the hard
Segher Boessenkool writes:
>> /* Make sure that the value that is to be substituted for the register
>> does not use any registers whose values alter in between. However,
>> If the insns are adjacent, a use can't cross a set even though we
>> think it might (this can happe
On Tue, Nov 19, 2019 at 11:33:13AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
> >> While working on SVE, I've noticed several cases in which we fail
> >> to combine instructions because the combined form would
Segher Boessenkool writes:
> On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
>> While working on SVE, I've noticed several cases in which we fail
>> to combine instructions because the combined form would need to be
>> placed earlier in the instruction stream than the last of th
Hi!
On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
> While working on SVE, I've noticed several cases in which we fail
> to combine instructions because the combined form would need to be
> placed earlier in the instruction stream than the last of the
> instructions being combi
Richard Sandiford writes:
> (It's 23:35 local time, so it's still just about stage 1. :-))
Or actually, just under 1 day after end of stage 1. Oops.
Could have sworn stage 1 ended on the 17th :-( Only realised
I'd got it wrong when catching up on Saturday's email traffic.
And inevitably, I int
On Sun, Nov 17, 2019 at 3:35 PM Richard Sandiford
wrote:
>
> (It's 23:35 local time, so it's still just about stage 1. :-))
>
> While working on SVE, I've noticed several cases in which we fail
> to combine instructions because the combined form would need to be
> placed earlier in the instruction
(It's 23:35 local time, so it's still just about stage 1. :-))
While working on SVE, I've noticed several cases in which we fail
to combine instructions because the combined form would need to be
placed earlier in the instruction stream than the last of the
instructions being combined. This inclu
32 matches
Mail list logo
