[Bug tree-optimization/79690] IVOPTs drops gs: prefix

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79690

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> But an extra assert like the following triggers during bootstrap so we can't
> really avoid the casting (in all cases).
> 
> Index: gcc/tree-ssa-address.c
> ===================================================================
> --- gcc/tree-ssa-address.c      (revision 245681)
> +++ gcc/tree-ssa-address.c      (working copy)
> @@ -708,6 +702,9 @@ create_mem_ref (gimple_stmt_iterator *gs
>    tree mem_ref, tmp;
>    struct mem_address parts;
>  
> +  if (base_hint)
> +    gcc_assert (POINTER_TYPE_P (TREE_TYPE (base_hint)));
> +
>    addr_to_parts (type, addr, iv_cand, base_hint, &parts, speed);
>    gimplify_mem_ref_parts (gsi, &parts);
>    mem_ref = create_mem_ref_raw (type, alias_ptr_type, &parts, true);
> 
> OTOH it looks harmless for a few cases I tried (the base_hint won't match
> in the search for it).  Testing w/o that assert.

Ok, so we'd move an integer to ->base and then later when building the
TARGET_MEM_REF we'd refuse that base and do

  else if (addr->base
           && POINTER_TYPE_P (TREE_TYPE (addr->base)))
    {
      base = addr->base;
      index2 = NULL_TREE;
    }
  else
    {
      base = build_int_cst (build_pointer_type (type), 0);
      index2 = addr->base;
    }

which cost-wide wasn't expected?  It's probably also not a good idea
in general to generate a zero-based TARGET_MEM_REF....

It's also against the very first check:

  if (verify
      && !valid_mem_ref_p (TYPE_MODE (type), TYPE_ADDR_SPACE (type), addr))
    return NULL_TREE;

which btw also uses a bogus type to get the address-space from.

So I think a better fix would be to ensure that TREE_TYPE (mem-ref) has
the same address-space as its pointed-to type in operand 0 ...