On Tue, Nov 5, 2013 at 8:29 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Tue, Nov 5, 2013 at 1:18 PM, Yufeng Zhang <yufeng.zh...@arm.com> wrote:
>> On 11/05/13 11:45, Bin.Cheng wrote:
>>>
>>> On Tue, Nov 5, 2013 at 7:19 PM, Yufeng Zhang<yufeng.zh...@arm.com> wrote:
>>>>
>>>> > On 11/05/13 10:13, bin.cheng wrote:
>>>>>
>>>>> >>
>>>>> >> Index: gcc/tree-affine.c
>>>>> >> ===================================================================
>>>>> >> --- gcc/tree-affine.c (revision 204117)
>>>>> >> +++ gcc/tree-affine.c (working copy)
>>>>> >> @@ -874,10 +874,11 @@ debug_aff (aff_tree *val)
>>>>> >> fprintf (stderr, "\n");
>>>>> >> }
>>>>> >>
>>>>> >> -/* Returns address of the reference REF in ADDR. The size of the
>>>>> >> accessed
>>>>> >> - location is stored to SIZE. */
>>>>> >> +/* Computes address of the reference REF in ADDR. The size of the
>>>>> >> accessed
>>>>> >> + location is stored to SIZE. Returns pointer to the ultimate
>>>>> >> containing
>>>>> >> + object to which REF refers. */
>>>>> >>
>>>>> >> -void
>>>>> >> +tree
>>>>> >> get_inner_reference_aff (tree ref, aff_tree *addr, double_int
>>>>> >> *size)
>>>>> >> {
>>>>> >> HOST_WIDE_INT bitsize, bitpos;
>>>>> >> @@ -904,6 +905,8 @@ get_inner_reference_aff (tree ref, aff_tree
>>>>> >> *addr,
>>>>> >> aff_combination_add (addr,&tmp);
>>>>> >>
>>>>> >> *size = double_int::from_shwi ((bitsize + BITS_PER_UNIT - 1) /
>>>>> >> BITS_PER_UNIT);
>>>>> >> +
>>>>> >> + return base_addr;
>>>>> >> }
>>>>> >>
>>>>
>>>> >
>>>> > I think what Richard suggests is to return the base object rather the
>>>> > address of the base object, i.e.
>>>
>>> I am not sure about that. We have to pass pointer_type expression to
>>> function determine_base_object for address expressions, because there
>>> is no way to tell pointer from object once we are in
>>> determine_base_object.
>>
>>
>> I'm just concerned with the consistency in what is returned between
>> get_inner_reference and get_inner_reference_aff. If determine_base_object
>> expects reference only, you can probably work around it with something like:
>>
>> base_object = build_fold_addr_expr (base_object);
>>
>> after the get_inner_reference_aff call.
>
> Note that get_inner_reference_aff is already different from
> get_inner_reference
> in that it does not separate base object and offset but lumps them together
> into an address represented as affine combination.
>
> For this reason get_inner_reference_aff may not exactly be the best
> name for the function ... it could be split to not do
>
> aff_combination_add (addr, &tmp);
>
> but instead return 'base'. The two existing users of the function could
> be unified into aff_comb_cannot_overlap_p (giving that a better name
> as well), even avoiding combining the base but instead handle
> comparing the base itself.
>
> Of course that's preexisting issues that I don't want to force Bin Cheng
> to clean up and fix (given I've, too, just spent a minute thinking about it).
>
I can investigate that later after finishing all my IVOPT patches.
Thanks,
bin
--
Best Regards.
