2014-09-19 23:45 GMT+04:00 Jeff Law <l...@redhat.com>: > On 09/16/14 03:09, Ilya Enkovich wrote: >>> >>> >>> I must be misunderstanding something then. I fundamentally don't see how >>> the return bounds are any different here than the return value. If we >>> have >>> exposed the bounds in the IL, then aren't they going to be handled just >>> like >>> any other object in the IL? >> >> >> They are not handled like any other object in IL because return block >> and all statements in it are not handled as all other statements we >> put into split part. >> >> Here is a comment from find_return_bb: >> >> /* Return basic block containing RETURN statement. We allow basic blocks >> of the form: >> <retval> = tmp_var; >> return <retval> >> but return_bb can not be more complex than this. >> ... >> */ >> >> Phi nodes also may present in return_bb. > > Right. I've seen this stuff, but it's still not clear to me what the real > issue is. > > The first thing that jumps out when I look at your dump is we don't have a > PHI for __bound_tmp.322 in BB6. Now it may be that we really just wanted > __bound_tmp.322_36, but that seems wrong as the return value varies > depending on how we reach BB6 and it seems to me the bounds ought to vary in > a similar manner.
Bounds don't have to vary for different pointers. E.g. p and p + 1 always have equal bounds. In this particular case we have function pointers and all of them have default bounds. > > > >> >> All blocks going to split part are analyzed by visit_bb function. >> Return basic block is not analyzed in the same way but still may be >> copied into split part in case return value is defined in it. There >> is a special code in visit_bb to add args of phi statements of >> return_bb as uses of split part to have no undefined values in copied >> block. It was enough when those phi args plus return value were only >> uses in return_bb. >> >> But now we add returned bounds to GIMPLE_RETURN as a new use and this >> new use is ignored. If split part returns value then return_bb will >> be copied into it. It means I should check returned bounds are >> defined there too. If SSA_NAME_DEF_STMT of returned bounds is in >> split part then it is OK. If SSA_NAME_DEF_STMT of returned bounds is >> in return_bb then it is also OK because it means it is a result of PHI >> node whose args were added as additional uses for split part earlier >> in visit_bb. >> >> At least that is how I think this happens :) >> >>> >>> Maybe you should post the IL for a case where this all matters and walk >>> me >>> through the key issues. >> >> >> I attach a dump I got from Chrome compilation with no additional >> checks restrictions in split. Original function returns value defined >> by phi node in return_bb and bounds defined in BB2. Split part >> contains BB3, BB4 and BB5 and resulting function part has usage of >> returned bounds but no producer for it. > > Right, but my question is whether or not the bounds from BB2 were really the > correct bounds to be using in the first place! I would have expected a PHI > in BB6 to select the bounds based on the path leading to BB6, much like we > select a different return value. Consider we have pointer computation and then return __bnd_init_ptr_bounds (res); In such case you would never have a PHI node for bounds. Also do not forget that we may have no PHI nodes for both return value and return bounds. In such case we could also easily fall into undefined value as in dump. Thanks, Ilya > > Jeff
