public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@redhat.com>
To: Christophe Lyon <christophe.lyon@linaro.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: a patch for PR68695
Date: Fri, 01 Apr 2016 20:26:00 -0000	[thread overview]
Message-ID: <56FED981.1020609@redhat.com> (raw)
In-Reply-To: <CAKdteOahR87wrjssCmrTuUZD+776xUWN207xRj2VOmDER04xAA@mail.gmail.com>

On 03/30/2016 05:23 PM, Christophe Lyon wrote:
> On 29 March 2016 at 18:28, Vladimir Makarov <vmakarov@redhat.com> wrote:
>>    The following patch improves the code in 2 out of 3 cases in
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
>>
>>    The patch uses more accurate costs for the RA cost improvement
>> optimization after colouring.
>>
>>    The patch was tested and bootstrapped on x86-64.  It is hard to create a
>> test to check the correct code generation.  Therefore there is no test.  As
>> the patch changes heuristics, a generated code in some cases will be
>> different but at least x86-64 tests expecting a specific code are not broken
>> by the patch.
>>
>>    Committed as rev.  234527
>>
> Hi,
>
> I've noticed that after this patch, 2 tests regress (PASS -> FAIL) on arm:
>    gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue
> "Performing shrink-wrapping"
>    gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"
>

I've checked the generated code.  RA with the patch generates a better 
code for the both tests. So shrink wrap optimization failed. The final 
code has 1 insn less for the both tests when the patch is applied.

I guess it is wrong to write quality tests based on expected code 
generated before any optimization.  It has sense if we provide the same 
input.  LLVM testsuite is mostly such tests as they have a readable IR.  
GCC unfortunately has no serialized and readable IR. On the other hand 
LLVM lacks integrated testing.

So I'd mark these tests as XFAIL or removed arm from DEJAGNU target in 
the tests.


  parent reply	other threads:[~2016-04-01 20:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 16:50 Vladimir Makarov
2016-03-30 21:40 ` Christophe Lyon
2016-04-01 17:45   ` Vladimir Makarov
2016-04-01 20:26   ` Vladimir Makarov [this message]
2016-04-01 20:43     ` Jakub Jelinek
2016-04-05  9:49       ` Kyrill Tkachov
2016-04-05 22:35         ` Segher Boessenkool
2016-04-15 11:06           ` Kyrill Tkachov
2016-04-15 16:18             ` Jeff Law
2016-04-15 16:21               ` Kyrill Tkachov
2016-04-15 16:23                 ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56FED981.1020609@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).