public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jeff Law <law@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces
Date: Wed, 30 Oct 2013 12:40:00 -0000	[thread overview]
Message-ID: <CAMbmDYb8GDOC74XY7ecBVNoThRaNyNzE6vywUPbeNsFuSeZzFQ@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc2FYcZ-j0+O80QH8pN7aqfhzWJ0ENkcm3a2w0FVD6efew@mail.gmail.com>

2013/10/30 Richard Biener <richard.guenther@gmail.com>:
> On Wed, Oct 30, 2013 at 11:34 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> On 30 Oct 10:26, Richard Biener wrote:
>>>
>>> Ick - you enlarge all return statements?  But you don't set the actual value?
>>> So why allocate it with 2 ops in the first place??
>>
>> When return does not return bounds it has operand with zero value similar to case when it does not return value. What is the difference then?
>>
>>>
>>> [Seems I completely missed that MPX changes "gimple" and the design
>>> document that was posted somewhere??]
>>>
>>
>> Design is on GCC Wiki and link was posted few times: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler. Here is quote about return statements:
>>
>> Returns instrumentation. We add new operand to return statement to hold returned bounds and instrumentation pass is responsible to fill this operand with correct bounds
>
> foo (int * p, unsigned int size)
> {
>   <unnamed type> __bound_tmp.0;
>   long unsigned int D.2239;
>   long unsigned int _2;
>   sizetype _6;
>   int * _7;
>
>   <bb 3>:
>   __bound_tmp.0_4 = __builtin_ia32_arg_bnd (p_3(D));
>
>   <bb 2>:
>   _2 = (long unsigned int) size_1(D);
>   __builtin_ia32_bndcl (__bound_tmp.0_4, p_3(D));
>   _6 = _2 + 18446744073709551615;
>   _7 = p_3(D) + _6;
>   __builtin_ia32_bndcu (__bound_tmp.0_4, _7);
>   access_and_store (p_3(D), __bound_tmp.0_4, size_1(D));
>
> so it seems there is now a mismatch between DECL_ARGUMENTS
> and the GIMPLE call stmt arguments.  How (if) did you amend
> the GIMPLE stmt verifier for this?

Verifier just ignores bound arguments while iterating through them.

>
> How does regular code deal with this which may expect matching
> to DECL_ARGUMENTS?  In fact interleaving the additional
> arguments sounds very error-prone for existing code - I'd have
> appended all bound args at the end.  Also you unconditionally
> claim all pointer arguments have a bound - that looks like bad
> design as well.  Why didn't you add a flag to the relevant
> PARM_DECL (and then, what do you do for indirect calls?).

I'll consider using another layout for bound args. But why should we
have any PARM_DECL or other pointer not having bounds?
>
> /* Return the number of arguments used by call statement GS
>    ignoring bound ones.  */
>
> static inline unsigned
> gimple_call_num_nobnd_args (const_gimple gs)
> {
>   unsigned num_args = gimple_call_num_args (gs);
>   unsigned res = num_args;
>   for (unsigned n = 0; n < num_args; n++)
>     if (POINTER_BOUNDS_P (gimple_call_arg (gs, n)))
>       res--;
>   return res;
> }
>
> the choice means that gimple_call_num_nobnd_args is not O(1).

Yes. And even having all bound args at the end would not fix it. We
have to additionally keep number of bounds if want to fix it. But I do
not see the strong reason for that. Currently there are just three
calls to this function in whole GCC.

>
> /* Return INDEX's call argument ignoring bound ones.  */
> static inline tree
> gimple_call_nobnd_arg (const_gimple gs, unsigned index)
> {
>   /* No bound args may exist if pointers checker is off.  */
>   if (!flag_check_pointer_bounds)
>     return gimple_call_arg (gs, index);
>   return gimple_call_arg (gs, gimple_call_get_nobnd_arg_index (gs, index));
> }
>
> GIMPLE layout depending on flag_check_pointer_bounds sounds
> like a recipie for desaster if you consider TUs compiled with and
> TUs compiled without and LTO.  Or if you consider using
> optimized attribute with that flag.

Yep. Marking instrumented calls and functions would be useful in LTO case.

>
> I wish I had seen all this before.
>
>>> Bah.
>>>
>>> Where is the update to gimple.texi and tree.texi?
>>>
>>> Richard.
>>>
>>
>> Unfortunately patch has been already installed.  Should we uninstall it?  If not, then here is patch for documentation.
>
> I hope the reviewers that approved the patch will work with you to
> address the above issues.  I can't be everywhere.

Thanks for valuable input!

Ilya

>
> Richard.
>
>> Thanks,
>> Ilya
>> --
>>
>> gcc/
>>
>> 2013-10-30  Ilya Enkovich  <ilya.enkovich@intel.com>
>>
>>         * doc/gimple.texi (gimple_call_num_nobnd_args): New.
>>         (gimple_call_nobnd_arg): New.
>>         (gimple_return_retbnd): New.
>>         (gimple_return_set_retbnd): New.
>>         (gimple_call_get_nobnd_arg_index): New.
>>
>>
>> diff --git a/gcc/doc/gimple.texi b/gcc/doc/gimple.texi
>> index 7bd9fd5..be74170 100644
>> --- a/gcc/doc/gimple.texi
>> +++ b/gcc/doc/gimple.texi
>> @@ -1240,11 +1240,25 @@ Set @code{CHAIN} to be the static chain for call statement @code{G}.
>>  Return the number of arguments used by call statement @code{G}.
>>  @end deftypefn
>>
>> +@deftypefn {GIMPLE function} unsigned gimple_call_num_nobnd_args (gimple g)
>> +Return the number of arguments used by call statement @code{G}
>> +ignoring bound ones.
>> +@end deftypefn
>> +
>>  @deftypefn {GIMPLE function} tree gimple_call_arg (gimple g, unsigned index)
>>  Return the argument at position @code{INDEX} for call statement @code{G}.  The
>>  first argument is 0.
>>  @end deftypefn
>>
>> +@deftypefn {GIMPLE function} tree gimple_call_nobnd_arg (gimple g, unsigned index)
>> +Return the argument at position @code{INDEX} for call statement @code{G}
>> +ignoring bound ones.  The first argument is 0.
>> +@end deftypefn
>> +
>> +@deftypefn {GIMPLE function} unsigned gimple_call_get_nobnd_arg_index (gimple g, unsigned index)
>> +Return index of @code{INDEX}'s non bound argument of the call statement @code{G}
>> +@end deftypefn
>> +
>>  @deftypefn {GIMPLE function} {tree *} gimple_call_arg_ptr (gimple g, unsigned index)
>>  Return a pointer to the argument at position @code{INDEX} for call
>>  statement @code{G}.
>> @@ -2029,6 +2043,15 @@ Return the return value for @code{GIMPLE_RETURN} @code{G}.
>>  Set @code{RETVAL} to be the return value for @code{GIMPLE_RETURN} @code{G}.
>>  @end deftypefn
>>
>> +@deftypefn {GIMPLE function} tree gimple_return_retbnd (gimple g)
>> +Return the bounds of return value for @code{GIMPLE_RETURN} @code{G}.
>> +@end deftypefn
>> +
>> +@deftypefn {GIMPLE function} void gimple_return_set_retbnd (gimple g, tree retbnd)
>> +Set @code{RETBND} to be the bounds of return value for @code{GIMPLE_RETURN}
>> +@code{G}.
>> +@end deftypefn
>> +
>>  @node @code{GIMPLE_SWITCH}
>>  @subsection @code{GIMPLE_SWITCH}
>>  @cindex @code{GIMPLE_SWITCH}

  parent reply	other threads:[~2013-10-30 11:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 12:37 Ilya Enkovich
2013-10-24 14:53 ` Ilya Enkovich
2013-10-29 20:24   ` Jeff Law
2013-10-29 22:24     ` Ilya Enkovich
2013-10-30  9:34       ` Richard Biener
2013-10-30 10:41         ` Ilya Enkovich
2013-10-30 10:55           ` Richard Biener
2013-10-30 10:58             ` Richard Biener
2013-10-30 12:40             ` Ilya Enkovich [this message]
2013-10-30 17:47             ` Jeff Law
2013-10-30 18:45               ` Ilya Enkovich
2013-10-30 19:55                 ` Jeff Law
2013-11-04 12:41               ` Richard Biener
2013-11-07 18:54                 ` Jeff Law
2013-11-07 21:40                   ` Ilya Enkovich
2013-11-11 13:48                     ` Richard Biener
2013-11-11 14:09                       ` Ilya Enkovich
2013-10-30 17:08           ` Jeff Law
2013-10-30 19:22             ` Ilya Enkovich
2013-11-04 12:40             ` Richard Biener
2013-10-30 16:17         ` 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=CAMbmDYb8GDOC74XY7ecBVNoThRaNyNzE6vywUPbeNsFuSeZzFQ@mail.gmail.com \
    --to=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.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).