This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934)


On Thu, Jun 8, 2017 at 6:29 PM, Martin Sebor <msebor@gmail.com> wrote:
> On 06/08/2017 01:51 AM, Richard Biener wrote:
>>
>> On Thu, Jun 8, 2017 at 4:33 AM, Martin Sebor <msebor@gmail.com> wrote:
>>>
>>> On 06/07/2017 02:12 PM, Martin Sebor wrote:
>>>>
>>>>
>>>> On 06/07/2017 02:01 PM, Marc Glisse wrote:
>>>>>
>>>>>
>>>>> On Wed, 7 Jun 2017, Bernhard Reutner-Fischer wrote:
>>>>>
>>>>>> On 7 June 2017 16:46:53 CEST, Martin Sebor <msebor@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 06/07/2017 02:23 AM, Richard Biener wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 7, 2017 at 5:26 AM, Martin Sebor <msebor@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note I'd be _much_ more sympathetic to simply canonicalizing all
>>>>>>>>>> of
>>>>>>>>>> bzero and bcopy
>>>>>>>>>> to memset / memmove and be done with all the above complexity.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Attached is an updated patch along these lines.  Please let me
>>>>>>>>> know if it matches your expectations.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think you attached the wrong patch.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes I did, sorry.  The correct one is attached.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Under POSIX.1-2008 "optimizing" bzero or bcmp is IMO plain wrong.
>>>>>>
>>>>>> It's like optimizing foo() to a random built-in but maybe that's just
>>>>>> me. If your libc provides a define to a standard function for these
>>>>>> under a compat knob then fine but otherwise you should fix that.
>>>>>> *shrug*. Joseph?
>>>>>
>>>>>
>>>>>
>>>>> The patch optimizes __builtin_bzero, which should be ok. The question
>>>>> (independent from this patch) is then under what conditions bzero
>>>>> should
>>>>> be detected as a builtin.
>>>>
>>>>
>>>>
>>>> Yes.  The problem is that unlike for C and C++, GCC doesn't have
>>>> a mechanism to select the target version of POSIX.  I think it
>>>> should.
>>>>
>>>> But there is a subtle problem with the patch that needs fixing.
>>>> Bcopy should not be transformed to memcpy but rather memmove.
>>>> I'll fix that before committing.
>>>
>>>
>>>
>>> Attached is an updated patch with this fix.  I also added a cast
>>> from bcopy and bzero to void to detect accidental uses of the
>>> return value.  Tested on x86_64-linux.
>>
>>
>> Please do not add foldings to builtins.c but instead add them to
>> gimple-fold.c.
>
>
> Sure.  Attached is an adjusted patch.
>
>>
>> +  /* Call memset and return the result cast to void to detect its use
>> +     (bzero returns void).  */
>> +  tree call = build_call_expr_loc (loc, fn, 3, dst, integer_zero_node,
>> len);
>> +  return fold_convert (void_type_node, call);
>>
>> ???  How can the result be used if the original call result was not?
>
>
> The cast ensured GCC would continue to warn on code like:
>
>   void f (void *d, unsigned n)
>   {
>     return bzero (d, n);
>   }
>
> Without the cast (as in the first patch) the above was silently
> accepted.
>
> This isn't necessary when the folding is done in gimple-fold.c.

+static bool
+gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi)
+{

+  /* Transform bcmp (a, b, len) into memcmp (a, b, len).  */
+
+  gimple *stmt = gsi_stmt (*gsi);
+  tree a = gimple_call_arg (stmt, 0);
+  tree b = gimple_call_arg (stmt, 1);
+  tree len = gimple_call_arg (stmt, 2);
+
+  gimple_seq seq = NULL;
+  gimple *repl = gimple_build_call (fn, 3, a, b, len);
+  gimple_seq_add_stmt_without_update (&seq, repl);
+  gsi_replace_with_seq_vops (gsi, seq);

given they have the same prototype you can do like gimple_fold_builtin_stpcpy:

  gimple_call_set_fndecl (stmt, fn);
  fold_stmt (gsi);

That works even with bcopy -> memmove if you swap arguments.

Ok with that changes.

Thanks,
Richard.

> Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]