bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Bruno Haible <bruno@clisp.org>]

Pip Cet wrote:
> Or, more realistically:
> 
> extern int potentially_inlined_function(int i);
> 
> int main(void)
> {
>   ...
>   eassume(potentially_inlined_function(i));
>   return i >= 0;
> }

OK, I see...

> This makes it safe to use function expressions in eassume, whether the
> function is inlined or not.

By "safe" you mean that you want the function call to not be evaluated.

You are mentioning a limitation:

> eassume(i >= 0 && i < complicated_function ());
> 
> will not "split" the && expression, so it'll behave differently from
> 
> eassume(i >= 0);
> eassume(i < complicated_function ());

And I would mention a regression: When -flto is in use and the expression
invokes an external potentially-inlined function, the old 'assume' would
work fine, i.e. do optimizations across compilation-unit boundaries.
Whereas the new 'assume' does not.

Test case:
================================ foo.c =================================
#include <stdio.h>

#define assume(R) ((R) ? (void) 0 : __builtin_unreachable ())
//#define assume(R) (!__builtin_constant_p (!(R) == !(R)) || (R) ? (void) 0 : __builtin_unreachable ())

extern int complicated (int i);
extern int nonnegative (int i);

int f_generic (int i)
{
  printf("%d\n", i & 0x80000000);
  return 0;
}

int f_condition (int i)
{
  if (complicated (i) && i >= 0)
    printf("%d\n", i & 0x80000000);
  return 0;
}

int f_assume (int i)
{
  assume (complicated (i) && i >= 0);
  printf("%d\n", i & 0x80000000);
  return 0;
}
================================= bar.c ================================
int complicated (int i) { return (i & 7) == 3; }
int nonnegative (int i) { return i >= 0; }
========================================================================
$ gcc -O2 -m32 -flto foo.c bar.c -shared -o libfoo.so && objdump --disassemble libfoo.so

With the old 'assume':

000005f0 <f_assume>:
 5f0:   83 ec 10                sub    $0x10,%esp
 5f3:   6a 00                   push   $0x0
 5f5:   68 74 06 00 00          push   $0x674
 5fa:   6a 01                   push   $0x1
 5fc:   e8 fc ff ff ff          call   5fd <f_assume+0xd>
 601:   31 c0                   xor    %eax,%eax
 603:   83 c4 1c                add    $0x1c,%esp
 606:   c3                      ret    
 607:   89 f6                   mov    %esi,%esi
 609:   8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

With the new 'assume':

00000610 <f_generic>:
 610:   83 ec 10                sub    $0x10,%esp
 613:   8b 44 24 14             mov    0x14(%esp),%eax
 617:   25 00 00 00 80          and    $0x80000000,%eax
 61c:   50                      push   %eax
 61d:   68 48 06 00 00          push   $0x648
 622:   6a 01                   push   $0x1
 624:   e8 fc ff ff ff          call   625 <f_generic+0x15>
 629:   31 c0                   xor    %eax,%eax
 62b:   83 c4 1c                add    $0x1c,%esp
 62e:   c3                      ret    
 62f:   90                      nop

00000630 <f_assume>:
 630:   eb de                   jmp    610 <f_generic>

> But even in those cases, this approach is better than the old approach
> of actually evaluating complicated_function.

I disagree that it is better:
  1. The new 'assume' is worse when -flto is in use.
  2. You recommend to users to split assume(A && B) into assume(A); assume(B);
     which is unnatural.

> At first, I thought it would be better to have a __builtin_assume
> expression at the GCC level, but even that would have to have "either
> evaluate the entire condition expression, or evaluate none of it"
> semantics.

No. At GCC level, it could have a "make the maximum of inferences - across
all optimization phases -, but evaluate none of it" semantics.

Bruno