Re: IVOPTS vs Ada subtypes and base types

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
>      When I speak about doing arithmetic in a type, I'm referring to the
>      type of the expression & its input operands in a gimplified
>      expression.  At that point I do not care about base types or anything
>      like that.  All that should matter is TREE_TYPE (expr), nothing more,
>      nothing less.  How the inputs are converted or how the output is later
>      converted is not a concern -- all that matters is TREE_TYPE (expr) in
>      a gimplified tree.
> 
>      Can we agree on that?
> 
> Yes.
> 
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes that don't actually change anything.)
Scratch my last message (February *really* isn't my month).

A day away and I had forgotten that there are two hunks of code
which effectively do the same thing (due to early jump threading)
I was looking at the first hunk when I came to the conclusion
that we were doing all the arithmetic in the base type.

It turns out that IVOPTS mucks up the second hunk of code and
removes all the conversions into the base type!  GRRRRR

Before IVOPTS we have:

  # BLOCK 5 freq:8574
  # PRED: 8 [95.0%]  (false,exec)
<L1>:;
  last.70_35 = (integer) last_22;
  D.2061_36 = last.70_35 + 1;
  last_37 = (natural___XDLU_0__2147483647) D.2061_36;
  last.70_40 = (integer) last_37;
  last.71_41 = (<unnamed type>) last.70_40;
  D.2065_42 = (character) D.2066_44;
  #   TMT.422_55 = V_MAY_DEF <TMT.422_58>;
  VIEW_CONVERT_EXPR<character[D.2045:D.2047]>(*item
$P_ARRAY_1)[last.71_41]{lb: D.2041_6 sz: 1} = D.2065_42;
  if (D.2043_9 == last.70_40) goto <L13>; else goto <L14>;
  # SUCC: 6 [5.0%]  (loop_exit,true,exec) 7 [95.0%]
(dfs_back,false,exec)


Which looks like exactly what we want.  We convert last_22 into the
base type and store the result in last.70_35.  We then perform our
arithmetic storing the result into D.2061_36.  Then we convert the
result back into the original type, storing the result in last_37.

After IVOPTS we have:

  # BLOCK 5 freq:8574
  # PRED: 8 [95.0%]  (false,exec)
<L1>:;
  last_32 = last_22 + 1;
  last_37 = last_32;
  D.2065_42 = (character) D.2066_44;
  D.2988_38 = (character *) ivtmp.449_5;
  #   TMT.422_55 = V_MAY_DEF <TMT.422_58>;
  MEM[base: D.2988_38, offset:
1B]{VIEW_CONVERT_EXPR<character[D.2045:D.2047]>(*item
$P_ARRAY)[last.71]{lb: D.2041 sz: 1}} = D.2065_42;
  ivtmp.449_46 = ivtmp.449_5 + 1B;
  D.2989_43 = (natural___XDLU_0__2147483647) D.2041_6;
  D.2990_45 = (unsigned int) D.2043_9;
  D.2991_33 = (unsigned int) D.2041_6;
  D.2992_18 = D.2990_45 - D.2991_33;
  D.2993_17 = (natural___XDLU_0__2147483647) D.2992_18;
  D.2994_16 = D.2989_43 + D.2993_17;
  if (last_37 == D.2994_16) goto <L13>; else goto <L14>;
  # SUCC: 6 [5.0%]  (loop_exit,true,exec) 7 [95.0%]
(dfs_back,false,exec)

Note how the conversions have been lost.

Unfortuantely IVOPTS is a black box to me.

Zdenek, can you help here?

Jeff