public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>,
	Martin Sebor <msebor@gmail.com>
Cc: Aldy Hernandez <aldyh@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] add support for strnlen (PR 81384)
Date: Tue, 10 Jul 2018 14:34:00 -0000	[thread overview]
Message-ID: <edd5e707-0acb-7804-6cc7-b5b125f41091@redhat.com> (raw)
In-Reply-To: <CAFiYyc26usHrns8Lj+9YFy+SbJURGwKpN0AuaOd9mpU4GqwYvA@mail.gmail.com>

On 07/10/2018 08:25 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 07/10/2018 01:12 AM, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor <msebor@gmail.com> wrote:
>>>>
>>>> On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>>>>>    { dg-do run }
>>>>>    { do-options "-O2 -fno-tree-strlen" }  */
>>>>>
>>>>> ^^^^ I don't think this is doing anything.
>>>>>
>>>>> If you look at the test run you can see that -fno-tree-strlen is never
>>>>> passed (I think you actually mean -fno-optimize-strlen for that
>>>>> matter).  Also, the builtins.exp harness runs your test for an
>>>>> assortment of other flags, not just -O2.
>>>>
>>>> I didn't know the harness ignores dg-options specified in these
>>>> tests.  That's surprising and feels like a bug in the harness
>>>> not to complain about it.  The purpose of the test is to verify
>>>> that the strnlen expansion in builtins.c does the right thing
>>>> and it deliberately tries to disable the earlier strlen
>>>> optimizations to make sure the expansion in builtins.c is fully
>>>> exercised.  By not pointing out my mistake the harness effectively
>>>> let me commit a change without making sure it's thoroughly tested
>>>> (I tested it manually before committing the patch but things could
>>>> regress without us noticing).  I'll look into fixing this somehow.
>>>>
>>>>>
>>>>> This test is failing on my range branch for -Og, because
>>>>> expand_builtin_strnlen() needs range info:
>>>>>
>>>>> +  wide_int min, max;
>>>>> +  enum value_range_type rng = get_range_info (bound, &min, &max);
>>>>> +  if (rng != VR_RANGE)
>>>>> +    return NULL_RTX;
>>>>>
>>>>> but interestingly enough, it seems to be calculated in the sprintf
>>>>> pass as part of the DOM walk:
>>>>>
>>>>>       /* First record ranges generated by this statement.  */
>>>>>       evrp_range_analyzer.record_ranges_from_stmt (stmt, false);
>>>>>
>>>>> It feels wrong that the sprintf warning pass is generating range info
>>>>> that you may later depend on at rtl expansion time (and for a totally
>>>>> unrelated thing-- strlen expansion).
>>>>
>>>> Any pass that records ranges for statements will have this
>>>> effect.  The sprintf pass seems to be the first one to make
>>>> use of this utility (and it's not just a warning pass but also
>>>> an optimization pass) but it would be a shame to put it off
>>>> limits to warning-only passes only because it happens to set
>>>> ranges.
>>>
>>> As you noted elsewhere warning options shouldn't change code-generation.
>>> This means that ranges may not be set to the IL in case they are only
>>> computed when a warning option is enabled.
>>
>> I agree.  That's also why I think it should be a basic service
>> rather than a side-effect of tree traversal, either one done
>> to implement a particular optimization, or one done by a warning.
>>
>> The main reason for the work Jeff put in to extracting it out
>> of EVRP, if I recall correctly, was to expose more accurate
>> range information to warning passes.  Would setting statement
>> ranges make sense as part of EVRP (or some other similar pass)?
>> If not, the only way to conform to the policy that I can think
>> of is to have warning-only  passes that need it make
>> the traversal and call record_ranges regardless of whether or
>> not the warning itself is enabled.  That would seem needlessly
>> inefficient, even if the code implementing the warning itself
>> were disabled.
> 
> Well, simply not set range-info on SSA names but use the
> lattice values?  Should be easy to key that to a flag.
Right.  That was essentially my suggestion.  For a client that uses EVRP
analysis to drive warnings, they do not mirror results into the global
range info we attach to SSA_NAMEs.  An optimization pass which utilizes
EVRP can (of course) set the global range info.

THe sprintf bits are a bit tricky as it's a mix of warning and
optimization, but I think there's enough separation that we can arrange
to do the right thing.

Since I introduced EVRP into the sprintf bits, I'm happy to own fixing
this up.  I just wanted to get general agreement on the approach.

jeff

  reply	other threads:[~2018-07-10 14:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 21:43 Martin Sebor
2018-06-05 22:20 ` Jakub Jelinek
2018-06-06 15:14   ` Martin Sebor
2018-06-06 15:49     ` Jakub Jelinek
2018-06-06  0:39 ` Eric Gallager
2018-06-06 14:44   ` Martin Sebor
2018-06-12 15:10 ` PING " Martin Sebor
2018-06-12 21:11 ` Jeff Law
2018-06-18 16:35   ` Martin Sebor
2018-07-09 14:36     ` Aldy Hernandez
2018-07-09 19:51       ` Jeff Law
2018-07-09 20:51         ` Martin Sebor
2018-07-09 21:26       ` Martin Sebor
2018-07-10  7:13         ` Richard Biener
2018-07-10 14:10           ` Martin Sebor
2018-07-10 14:25             ` Richard Biener
2018-07-10 14:34               ` Jeff Law [this message]
2018-07-10 14:57                 ` Martin Sebor
2018-06-19 19:33 David Edelsohn
2018-06-19 20:10 ` Martin Sebor
2018-06-19 20:25   ` Martin Sebor
2018-06-20  5:24   ` 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=edd5e707-0acb-7804-6cc7-b5b125f41091@redhat.com \
    --to=law@redhat.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    --cc=richard.guenther@gmail.com \
    /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).