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
