This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Ilya Enkovich <enkovich dot gnu at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 4 Nov 2013 13:32:16 +0100
- Subject: Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces
- Authentication-results: sourceware.org; auth=none
- References: <20131021122236 dot GE37888 at msticlxl57 dot ims dot intel dot com> <20131024144329 dot GB39638 at msticlxl57 dot ims dot intel dot com> <52700F0A dot 3010606 at redhat dot com> <20131029215323 dot GA46971 at msticlxl57 dot ims dot intel dot com> <CAFiYyc3Y9z_6TigcZYhMbHh=nPNuE7HqpcXK+mQUw=JQmWeCDw at mail dot gmail dot com> <20131030103410 dot GB46971 at msticlxl57 dot ims dot intel dot com> <527131DA dot 4020404 at redhat dot com>
On Wed, Oct 30, 2013 at 5:20 PM, Jeff Law <email@example.com> wrote:
> On 10/30/13 04:34, Ilya Enkovich 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
> In general, when someone proposes a change in the size of tree, rtl or
> gimple nodes, it's a "yellow flag" that something may need further
> In this specific instance, I could trivially predict how that additional
> field would be used and a GIMPLE_RETURN isn't terribly important from a size
> standpoint, so I didn't call it out.
Btw, both for regular return with no value and this case only required
operands could be allocated. There may be legacy issues with
the regular return value but for new uses always allocating the
operand seems wrong (even if "cheap" in practice).
>> 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
> Exactly what I expected.
>> Unfortunately patch has been already installed. Should we uninstall
>> it? If not, then here is patch for documentation.
> I think we're OK for now. If Richi wants it out, he'll say so explicitly.
>> Thanks, Ilya --
>> 2013-10-30 Ilya Enkovich <firstname.lastname@example.org>
>> * 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):
> Can you also fixup the GIMPLE_RETURN documentation in gimple.texi. It needs
> a minor update after these changes.