On 10/16/2017 04:56 AM, Wilco Dijkstra wrote:
> This patch cleans up autopref scheduling.
>
> The code is greatly simplified. Sort accesses on the offset first, and
> only if the offsets are the same fall back to other comparisons in
> rank_for_schedule. This doesn't at all restore the original
> On Oct 16, 2017, at 1:56 PM, Wilco Dijkstra wrote:
>
> This patch cleans up autopref scheduling.
>
> The code is greatly simplified. Sort accesses on the offset first, and
> only if the offsets are the same fall back to other comparisons in
> rank_for_schedule. This doesn't at all restore th
This patch cleans up autopref scheduling.
The code is greatly simplified. Sort accesses on the offset first, and
only if the offsets are the same fall back to other comparisons in
rank_for_schedule. This doesn't at all restore the original behaviour
since we no longer compare the base address, b
Maxim Kuvyrkov wrote:
Note I've committed: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00309.html
which does
change qsort to (qsort) like Jakub proposed.
> I think that this is the best solution so far. Could you add a comment like
> the following?
> ==
> Ideally, we would call autopref_rank
> On Oct 5, 2017, at 11:28 PM, Alexander Monakov wrote:
>
> On Thu, 5 Oct 2017, Maxim Kuvyrkov wrote:
>> I'm still working on analysis, but it appears to me that Alexander's patch
>> (current state of trunk) fails qsort check due to not being symmetric for
>> load/store analysis (write == 0 or wr
On 5 October 2017 at 22:28, Alexander Monakov wrote:
> On Thu, 5 Oct 2017, Maxim Kuvyrkov wrote:
>> I'm still working on analysis, but it appears to me that Alexander's patch
>> (current state of trunk) fails qsort check due to not being symmetric for
>> load/store analysis (write == 0 or write ==
On Thu, 5 Oct 2017, Maxim Kuvyrkov wrote:
> I'm still working on analysis, but it appears to me that Alexander's patch
> (current state of trunk) fails qsort check due to not being symmetric for
> load/store analysis (write == 0 or write == 1) in comparisons with
> "irrelevant" instructions. Wilco
Maxim Kuvyrkov wrote:
> What the heck, I'll jump in as well.
Why not - how many engineers does it take to sort?!?
> I'm still working on analysis, but it appears to me that Alexander's patch
> (current state of trunk) fails qsort check due to not being symmetric for
> load/store analysis (write
On Thu, 2017-10-05 at 20:33 +0300, Maxim Kuvyrkov wrote:
> I'm currently bootstrapping the following patch (on aarch64-linux-
> gnu, arm-linux-gnueabihf will follow tomorrow), which (like Wilco's
> patch) seems to unbreak bootstrap, but is less invasive and preserves
> handling of multi_mem_insns.
> On Oct 5, 2017, at 8:20 PM, Steve Ellcey wrote:
>
> On Wed, 2017-10-04 at 13:24 +, Wilco Dijkstra wrote:
>> Richard Sandiford wrote:
>>>
>>>
>>> I don't think it's reasonable to commit this as obvious. You said
>>> yourself in the covering message that "it doesn't at all restore
>>> the
On Wed, 2017-10-04 at 13:24 +, Wilco Dijkstra wrote:
> Richard Sandiford wrote:
> >
> >
> > I don't think it's reasonable to commit this as obvious. You said
> > yourself in the covering message that "it doesn't at all restore
> > the original behaviour since we no longer compare the base ad
> We have now had 5 days of no builds for a major target, which is a huge
> inconvenience. So I don't think it is reasonable to wait any longer.
well, to put things in perspective, you broke the SPARC compiler about one
month ago and have done anything AFAIK since then to repair the breakage so..
On Wed, Oct 04, 2017 at 02:12:11PM +0100, Ramana Radhakrishnan wrote:
> On Wed, Oct 4, 2017 at 12:01 PM, Richard Sandiford
> wrote:
> > Wilco Dijkstra writes:
> >> Christophe Lyon wrote:
> >>
> >>> FWIW, I confirm that this patch fixes the build failure I reported at:
> >>> https://gcc.gnu.org/ml
On Wed, Oct 4, 2017 at 2:39 PM, Alexander Monakov wrote:
> On Wed, 4 Oct 2017, Ramana Radhakrishnan wrote:
>> However we need a scheduler maintainer or global reviewer to please
>> help review this patch or help come up with an alternative patch. A
>> primary platform broken for 5 days with a comm
On Wed, 4 Oct 2017, Ramana Radhakrishnan wrote:
> However we need a scheduler maintainer or global reviewer to please
> help review this patch or help come up with an alternative patch. A
> primary platform broken for 5 days with a commit and no public
> response from the original poster is really
On Wed, Oct 04, 2017 at 01:24:15PM +, Wilco Dijkstra wrote:
> Well my understanding was that it is OK to fix a bootstrap failure. I believe
> my
> patch is trivial since it mostly removes redundant code. Also I took Jakub's
> review as an OK as there were no technical objections. However since
Richard Sandiford wrote:
>
> I don't think it's reasonable to commit this as obvious. You said
> yourself in the covering message that "it doesn't at all restore
> the original behaviour since we no longer compare the base address".
> So even with the bootstrap failure, I think the patch needed re
On Wed, Oct 4, 2017 at 12:01 PM, Richard Sandiford
wrote:
> Wilco Dijkstra writes:
>> Christophe Lyon wrote:
>>
>>> FWIW, I confirm that this patch fixes the build failure I reported at:
>>> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
>>
>> Thanks, now committed as r253399.
>
> I don
Wilco Dijkstra writes:
> Christophe Lyon wrote:
>
>> FWIW, I confirm that this patch fixes the build failure I reported at:
>> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
>
> Thanks, now committed as r253399.
I don't think it's reasonable to commit this as obvious. You said
yourself
Christophe Lyon wrote:
> FWIW, I confirm that this patch fixes the build failure I reported at:
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01980.html
Thanks, now committed as r253399.
Wilco
On 3 October 2017 at 18:34, Wilco Dijkstra wrote:
> r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
> behaviour on AArch64 as autopref scheduling no longer checks the base.
>
> This patch fixes the bootstrap failure and cleans up autopref scheduling.
> The code is grea
r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
behaviour on AArch64 as autopref scheduling no longer checks the base.
This patch fixes the bootstrap failure and cleans up autopref scheduling.
The code is greatly simplified. Sort accesses on the offset first, and
only
22 matches
Mail list logo
