From: Martin Sebor <msebor@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Rainer Orth <ro@cebitec.uni-bielefeld.de>,
Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: committed] correct memcmp expansion of constant representations containing embedded nuls (PR 95189)
Date: Thu, 23 Jul 2020 17:50:32 -0600 [thread overview]
Message-ID: <dbcca0df-caa5-8f8e-b699-730027d6fcc6@gmail.com> (raw)
In-Reply-To: <CAMe9rOpTfLT5SytSV6wnGybMtSv51m2wcf9uu-q98x8iDH+hTQ@mail.gmail.com>
On 7/23/20 2:18 PM, H.J. Lu wrote:
> On Thu, Jul 23, 2020 at 1:14 PM Martin Sebor via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> On 7/22/20 2:23 AM, Rainer Orth wrote:
>>> Hi Martin,
>>>
>>>> I have committed this change in r11-2231 after Jeff approved it
>>>> off list last Thursday.
>>>
>>> the new gcc.target/i386/memcpy-pr95886.c test FAILs on 32-bit x86
>>> (i386-pc-solaris2.11):
>>>
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 1976943448883713" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 576467370915332609" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578431098682540545" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695685198337" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695685198337" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695752110593" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695752306689" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695752307200" 1
>>> +FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int 578437695752307201" 2
>>
>> Thanks for letting me know. The test looks for patterns that are
>> apparently LP64-specific so I restricted it to just that data model.
>>
>
> Shouldn't it also work for x32?
I would expect the optimization to work on any target that does
the piecemeal copy, including x32. But you probably meant if
the test should pass as is on x32. Possibly yes, but I didn't
check.
A better test would exercise the solution at least on all three
i386 targets. It could probably be done fairly simply by reducing
the sizes of the arrays, or by using the large arrays only on LP64
or whatever makes the difference and figuring out the right magic
target selector to use in the dg- directives.
Martin
next prev parent reply other threads:[~2020-07-23 23:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 0:23 [PATCH] " Martin Sebor
2020-07-07 20:02 ` Martin Sebor
2020-07-14 0:06 ` [PING #2][PATCH] " Martin Sebor
2020-07-20 18:43 ` committed] " Martin Sebor
2020-07-22 8:23 ` Rainer Orth
2020-07-22 8:36 ` Iain Sandoe
2020-07-23 20:12 ` Martin Sebor
2020-07-23 20:18 ` H.J. Lu
2020-07-23 23:50 ` Martin Sebor [this message]
2020-07-24 2:26 ` H.J. Lu
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=dbcca0df-caa5-8f8e-b699-730027d6fcc6@gmail.com \
--to=msebor@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=ro@cebitec.uni-bielefeld.de \
/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).