Bug 23666 - Fold does not reduce C - ~a into a + (C+1)
Fold does not reduce C - ~a into a + (C+1)
Status: NEW
Product: gcc
Classification: Unclassified
Component: middle-end
4.1.0
: P2 enhancement
: ---
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on: 23295 25125
Blocks: 19987
  Show dependency treegraph
 
Reported: 2005-09-01 01:42 UTC by Andrew Pinski
Modified: 2007-07-01 00:51 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-07-01 00:51:27


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-09-01 01:42:09 UTC
The asm for the following two functions should be the same.
int f(int a)
{
  return 10 - ~a;
}
int f1(int a)
{
  return a + 11;
}


Found while reading LLVM's instruction combiner.
Comment 1 Falk Hueffner 2005-09-01 06:19:55 UTC
Works for me on alphaev68-unknown-linux-gnu
 tiw with 4.1.0 20050819.
Comment 2 Andrew Pinski 2005-09-01 11:59:57 UTC
(In reply to comment #1)
> Works for me on alphaev68-unknown-linux-gnu
>  tiw with 4.1.0 20050819.

And does not with 4.1.0 20050901 on i686-pc-linux-gnu or on powerpc-darwin.
Comment 3 Andrew Pinski 2005-09-17 02:11:51 UTC
Confirmed.
Comment 4 Andrew Pinski 2005-11-26 21:43:13 UTC
The problem here is my fault, slightly.  Fold is converting -(~a) in the NEGATE_EXPR but not in the generic functions to do the negation.  I will do the patch for this one.  (I am saying that -(~a) is more complex than a+1 which is true).
Comment 5 Andrew Pinski 2005-11-26 22:38:25 UTC
Actually there is two things that need to be done, first is what I said in comment # 4 and then the second thing is for MINUS_EXPR to use those functions instead of checking explicatly for NEGATE_EXPR.
Comment 6 Andrew Pinski 2005-11-26 22:53:54 UTC
Actually it is just a check for flag_wrapv which looks to be wrong as far as I can tell.
Comment 7 Andrew Pinski 2005-11-27 22:26:14 UTC
After the patch which I am about to test, we get this with -fwrapv (yes that is weird we get it with something which should be cause optimizations not to happen and not the other way around).
Comment 8 Andrew Pinski 2005-11-29 00:39:12 UTC
I am not going to fix this now as it exposes too many VRP issues and other issues.
Comment 9 Andrew Pinski 2005-11-30 16:48:23 UTC
This is exactly the same issue as PR 23295 now (I should copy some of the comments from here to there).
Comment 10 Richard Biener 2006-10-22 15:12:40 UTC
With the patch for 23295 we get the behavior as noted in comment #7.  This is due
to negate_expr_p (correctly) containing

    case BIT_NOT_EXPR:
       return INTEGRAL_TYPE_P (type)
              && (TYPE_UNSIGNED (type)
                  || (flag_wrapv && !flag_trapv));

as negating ~7ffffff will result in signed overflow which is undefined without flag_wrapv.