On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law <l...@redhat.com> wrote:
>> On 11/25/13 02:22, bin.cheng wrote:
>>
>> Unless there's a PR for this problem, I think this needs to wait.
>
> I agree. Btw, please split the patch.
Yes, I will get back to this after entering stage 1 again :)
Hi Richard,
I talked with you about clean strip_offset_1 up after this series of
base simplification patches, but I realized it's not safe because
affine facility has it's limit, like can only support 8 elements.
Though the cleanup passes bootstrap and test on x86/x86_64 and most of
codes in strip_offset_1 won't be executed usually, I guess we'd better
to live with it, so what do you think?
Thanks,
bin
>
> Index: gcc/tree-affine.c
> ===================================================================
> --- gcc/tree-affine.c (revision 205087)
> +++ gcc/tree-affine.c (working copy)
> @@ -328,7 +328,19 @@ tree_to_aff_combination (tree expr, tree type, aff
> double_int::from_uhwi (bitpos / BITS_PER_UNIT));
> core = build_fold_addr_expr (core);
> if (TREE_CODE (core) == ADDR_EXPR)
> - aff_combination_add_elt (comb, core, double_int_one);
> + {
> + /* Handle &MEM[ptr + CST] in core part of complex reference. */
> + if (TREE_CODE (TREE_OPERAND (core, 0)) == MEM_REF)
> + {
> + core = TREE_OPERAND (core, 0);
> + tree_to_aff_combination (TREE_OPERAND (core, 0), type, &tmp);
> + aff_combination_add (comb, &tmp);
> + tree_to_aff_combination (TREE_OPERAND (core, 1), sizetype, &tmp);
> + aff_combination_add (comb, &tmp);
> + }
> + else
> + aff_combination_add_elt (comb, core, double_int_one);
> + }
> else
> {
> tree_to_aff_combination (core, type, &tmp)
>
> please handle the offset before taking the address, thus
>
> if (TREE_CODE (core) == MEM_REF)
> {
> add constant offset;
> core = TREE_OPERAND (core, 0);
> }
> else
> core = build_fold_addr_expr (core);
>
> that simplifies things and avoids the address building.
>
> Richard.
>
>> jeff
>>
>>
--
Best Regards.
