[patch] expr.c: Fix PR middle-end/18008.

[Jeffrey A Law]

On Sun, 2004-10-17 at 10:21, Kazu Hirata wrote:
> Hi,
> 
> Attached is a patch to fix a regression, PR middle-end/18008.
> 
> Consider
> 
> struct B {
>   unsigned b : 2;
> };
> 
> void
> store (struct B *b, int v)
> {
>   b->b = v;
> }
> 
> After the tree optimizers run, I get
> 
>   b->b = (<unnamed type>) (unsigned char) v;
> 
> where <unnamed type> is a 2-bit integer type.  The problem is that we
> get ANDs from two places.  The first one is generated by the cast to
> (<unnamed type>).  The second one is from the assignment, more
> specifically store_bit_field.
> 
> The patch fixes the problem by stripping a narrowing conversion.
> 
> Personally, I don't like the way the patch fixes the problem because
> the tree optimizers make the types very strict for us so that we won't
> do a type-mismatched assignment, but now we are sort of breaking it.
> 
> Tested on i686-pc-linux-gnu.  Any comments?
Well, we could try to attack this earlier (in the tree optimizers).

If we look at the .dom3 dump we have:

  # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1122_2 = (unsigned char) v_1;
  D.1123_3 = (<unnamed type>) D.1122_2;
  #   TMT.0_6 = V_MAY_DEF <TMT.0_5>;
  b_4->b = D.1123_3;
  return;
  # SUCC: EXIT [100.0%]
                                                                                

I would think we could turn that into

 # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1122_2 = (unsigned char) v_1;   /* This will be removed */
  D.1123_3 = (<unnamed type>) v_1;  /* This line was changed */
  #   TMT.0_6 = V_MAY_DEF <TMT.0_5>;
  b_4->b = D.1123_3;
  return;
  # SUCC: EXIT [100.0%]



Which would result in the following .optimized

b->b = (<unnamed type>) v;

I don't know if that would help or not.  I also haven't investigated
how much work that would be.

An alternate approach is to fold statements after TER, which has the
same ultimate affect.  This is something I have played with and have
solid code around here to implement.  I never checked it in as most
of the stuff it was finding was stuff that ought to be addressed
earlier in the optimizer paths (such as the this example).

Jeff