> Am 07.09.2018 um 00:39 schrieb Segher Boessenkool
> <seg...@kernel.crashing.org>:
>
> On Thu, Sep 06, 2018 at 12:11:09PM -0600, Jeff Law wrote:
>> On 09/05/2018 06:11 AM, Richard Biener wrote:
>>> On Wed, Sep 5, 2018 at 2:01 PM Ilya Leoshkevich <i...@linux.ibm.com> wrote:
>>>> + /* Combining insns can change basic blocks in a way that they end up
>>>> + containing a single jump_insn. This creates an opportunity to
>>>> improve code
>>>> + with jump threading. */
>>>> + cleanup_cfg (CLEANUP_THREADING);
>
> Please show an example of when this happens. For almost all code it does
> not happen, so please don't do it always.
This improves the code for the following example from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080:
extern void bar(int *mem);
void foo5(int *mem)
{
int oldval = 0;
__atomic_compare_exchange_n (mem, (void *) &oldval, 1,
1, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
if (oldval != 0)
bar (mem);
}
I posted the corresponding RTL here:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00495.html
>
> Does it improve code at all? There is a reason we do not run the expensive
> cfg cleanups after every pass: they are expensive. They are only done in
> some strategically chosen places.
>
Performance-wise, the net win is insignificant (checked with SPEC
CPU2006), but nevertheless the generated code contains less redundant
jumps. I intended this to be a small unintrusive improvement, so it
definitely is not good if it would increase the compile times. I will
check how this affects build times of gcc master and SPEC CPU2006
benchmarks.
>
> Segher
>
