2013/10/30 Jeff Law <l...@redhat.com>: > 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 >> then? > > 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 > investigation. > > 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. > > > >> 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 -- >> >> gcc/ >> >> 2013-10-30 Ilya Enkovich <ilya.enkov...@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. > > Can you also fixup the GIMPLE_RETURN documentation in gimple.texi. It needs > a minor update after these changes.
I could not find anything but accessors for GIMPLE_RETURN in gimple.texi. And new accessors are in my doc patch already. Ilya > > jeff >
