Missed compiler optimization issue in function select_rtable_names_for_explain - Mailing list pgsql-general

From XChy
Subject Missed compiler optimization issue in function select_rtable_names_for_explain
Date
Msg-id OS0P286MB016392E0B2017DDB6709A11C82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM
Whole thread Raw
Responses Re: Missed compiler optimization issue in function select_rtable_names_for_explain
Re: Missed compiler optimization issue in function select_rtable_names_for_explain
List pgsql-general

Hi everyone,

I'm a compiler developer working on detecting missed optimization in real-world applications. Recently, we found that LLVM missed a dead store elimination optimization in the PostgreSQL code (https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/ruleutils.c#L3794) in the master branch.

For the example below:

```

int dst[128];

memset(dst, 0, 128);

*unrelated = some_value;

dst[1] = 0;

dst[2] = 0;

```

LLVM cannot eliminate the useless stores after memset since the store to "unrelated" clobbers. But if we put the stores to "dst" ahead of the store to "unrelated", we could prevent confusing the compiler. See also the compiler explorer link: https://godbolt.org/z/P9jnKod3v and the issue of LLVM: https://github.com/llvm/llvm-project/issues/88632

To improve the codegen quality, I think it's also possible to modify the source code, changing the order of initialization of the member, to get better optimization. But I don't know whether this can be considered as a bug, thus post the issue here.

If anyone could confirm this problem or post a patch for it, let me know please. Thanks!


Best regards. Hongyu.

pgsql-general by date:

Previous
From: Durgamahesh Manne
Date:
Subject: Regarding use case of epoch to generate nanoseconds precision
Next
From: Daniel Gustafsson
Date:
Subject: Re: Missed compiler optimization issue in function select_rtable_names_for_explain