> Am 04.10.2023 um 16:16 schrieb Hanke Zhang <hkzhang...@gmail.com>:
>
> Richard Biener <richard.guent...@gmail.com> 于2023年10月4日周三 16:43写道：
>>
>>> On Wed, Oct 4, 2023 at 10:37 AM Richard Biener
>>> <richard.guent...@gmail.com> wrote:
>>>
>>> On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
>>>>
>>>> Hi, I'm a little confused about the behavior of gcc when the function
>>>> is not inlined.
>>>>
>>>> Here is an example code:
>>>>
>>>> int __attribute__((noinline)) foo() {
>>>> return 1;
>>>> }
>>>>
>>>> int main() {
>>>> if (foo()) {
>>>> printf("foo() returned 1\n");
>>>> } else {
>>>> printf("foo() returned 0\n");
>>>> }
>>>> return 0;
>>>> }
>>>>
>>>> After compiling this via `-O3 -flto`, the else block isn't been
>>>> optimized and still exists.
>>>>
>>>> Even it's so obvious that the function will return '1', can't the
>>>> compiler see that? Does gcc only get this information by inlining the
>>>> function? Or is that what the gcc does?
>>>>
>>>> If so, how to make a change to let gcc get this information then?
>>>
>>> I think IPA-CP would be doing this but the issue is that historically
>>> 'noinline' also disabled other IPA transforms and we've kept that
>>> for backward compatibility even when we introduced the separate 'noipa'
>>> attribute.
>
> Thanks. The initial example is a function that uses va_args as
> parameters. It cannot be inlined because of va_args, and then its
> return value cannot be predicted like above. For example, the
> following function:
>
> int foo (int num, ...) {
> va_list args;
> va_start(args, num);
> int a1 = va_arg(args, int);
> int a2 = va_arg(args, int);
> printf("a1 = %d, a2 = %d\n", a1, a2);
> va_end(args);
> return 1;
> }
>
> int main() {
> if (foo(2, rand(), rand())) {
> printf("foo() returned 1\n");
> } else {
> printf("foo() returned 0\n");
> }
> return 0;
> }
>
> Wouldn't such a function be optimized like 'noinline'?
>
>>
>> Oh, and I forgot that IIRC neither IPA CP nor IPA SRA handle return
>> functions in a way exposing this to optimization passes (there's no
>> way to encode this in fnspec, we'd need some return value value-range
>> and record that and make VRP/ranger query it on calls).
>>
>> Richard.
>>
>
> Thanks. So, does that mean I have to let VRP/ranger be able to query
> the return value so that the else block can be optimized out?
Yes (and compute a return value range).
Richard
>>> Richard.
>>>
>>>>
>>>> Thanks
>>>> Hanke Zhang
