https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87325
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 18 Sep 2018, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87325 > > --- Comment #2 from bin cheng <amker at gcc dot gnu.org> --- > Seems alloc_iv doesn't infer base object correctly: > /* Lower address expression in base except ones with DECL_P as operand. > By doing this: > 1) More accurate cost can be computed for address expressions; > 2) Duplicate candidates won't be created for bases in different > forms, like &a[0] and &a. */ > STRIP_NOPS (expr); > if ((TREE_CODE (expr) == ADDR_EXPR && !DECL_P (TREE_OPERAND (expr, 0))) > || contain_complex_addr_expr (expr)) > { > aff_tree comb; > tree_to_aff_combination (expr, TREE_TYPE (expr), &comb); > base = fold_convert (TREE_TYPE (base), aff_combination_to_tree (&comb)); > } > > iv->base = base; > iv->base_object = determine_base_object (base); > > Given: > (gdb) call debug_generic_expr(expr) > &ts[1].y > > in which "ts" is a VAR_DECL in specific address space: > (gdb) call debug_generic_expr(*addr_p) > ts > (gdb) p (*addr_p)->base.code > $8 = VAR_DECL > (gdb) p (*addr_p)->typed.type->base.u.bits.address_space > $10 = 7 > > Question is, should be build appropriate pointer type for "ts[1].y", for now, > base = build_fold_addr_expr (base); > returns: > (gdb) call debug_generic_expr(base) > &ts[1].y > (gdb) call debug_generic_expr(base->typed.type) > float * I think build_fold_addr_expr handles things correctly since it uses built_pointer_type which should handle address-spaces correctly. The question is probably whether ts[1].y has the proper address-space qualified type (which IIRC it doesn't ...). So we'd need sth like ref_alias_ptr_type - a ref_addr_space () we can use to extract the address-space from an object and transfer that properly in build_fold_addr_expr (and elsewhere we run into this issue). Whereever RTL expansion takes the address-space from is probably the code to mimic in said new API.
