STRIP_NOPS and lower-precision/bit-field types

STRIP_NOPS and lower-precision/bit-field types

[Adam Nemet]

In this testcase:

  struct s
  {
    unsigned long a:2;
    unsigned long b:40;
    unsigned long c:22;
  };
  
  f (struct s s)
  {
    g (((unsigned long) (s.b-8)) + 8);
  }

fold breaks the code.  Specifically, after a few transformations we're asked
to fold this.  (I changed the big constant to be in symbolic form for better
understanding):

    <unnamed-unsigned:40> D.40719;
   (uint64_t) (D.40719 + ((1<<40) - 8)) + 8

The cast is removed by STRIP_NOPS so with explicit precision and signedness on
the operations we have (the constants are of types of the corresponding
operation):

   (D.40719 +:u40 ((1<<40) - 8)) +:u64 8

split_trees/associate_trees code combines the two constant resulting in:

  (uint64_t) D.40719 +:64 1<<40

Ouch.

The problem is obviously that we remove a zero-extension that would ensure the
modulo-2^40 nature of the addition (remove the overflow).

I see two ways to fix this:

1. Change STRIP_NOPS not to remove the cast if it's changing the precision
(not just when it changes machine modes).  And then audit code quality where
we need to and are allowed to look through these casts.

The above case does not qualify because the first operation may not overflow
into the >40 bits whereas the second may.  For example with 2 as s.b the
substraction should yield 0xff,ffff,fffa and the addition 0x100,0000,0002.
(Note that there in *no* default integer promotion on bitfield types wider
than int [1].)

2. Just fix this particular case of folding (split_trees/associate_trees) and
hope everything else works ;).

I am for 1, FWIW, but I know this issue has some history [2], so I'd like to
hear others' opinion before I started working on a patch.

Adam

[1] http://gcc.gnu.org/ml/gcc/2008-01/msg00215.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01478.html

Re: STRIP_NOPS and lower-precision/bit-field types

[Joseph S. Myers]

On Thu, 4 Jun 2009, Adam Nemet wrote:

> 1. Change STRIP_NOPS not to remove the cast if it's changing the precision
> (not just when it changes machine modes).  And then audit code quality where
> we need to and are allowed to look through these casts.

As I said in <http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg02228.html> and 
<http://gcc.gnu.org/ml/gcc/2008-01/msg00215.html>, I think such references 
to the mode are as a proxy for precision and machine modes are an 
inappropriate level of abstraction for the tree optimizers.  So I favour 
checking for precision here - but I also favour having a good look at 
anything using STRIP_NOPS etc. and considering whether it should use some 
better defined function for removing redundant conversions instead.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: STRIP_NOPS and lower-precision/bit-field types

[Richard Guenther]

On Thu, Jun 4, 2009 at 10:49 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Thu, 4 Jun 2009, Adam Nemet wrote:
>
>> 1. Change STRIP_NOPS not to remove the cast if it's changing the precision
>> (not just when it changes machine modes).  And then audit code quality where
>> we need to and are allowed to look through these casts.
>
> As I said in <http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg02228.html> and
> <http://gcc.gnu.org/ml/gcc/2008-01/msg00215.html>, I think such references
> to the mode are as a proxy for precision and machine modes are an
> inappropriate level of abstraction for the tree optimizers.  So I favour
> checking for precision here - but I also favour having a good look at
> anything using STRIP_NOPS etc. and considering whether it should use some
> better defined function for removing redundant conversions instead.

FWIW I agree.  STRIP_NOPS should not change the precision - we came
to this conclusion multiple times but never got around to do the change.

Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com
>