Re: [PATCH] for_each_string_list_item(): behave correctly for empty list
- From
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
- Date
- Sep 20, 2017, 07:35 UTC
- Message-ID
- <3467b198-8c8c-2bfa-b139-d3ed5ab6b8bc@gmail.com>
- In-Reply-To
- <20170920023008.GB126984@aiede.mtv.corp.google.com>
Hi,
Though this thread seems to have reached a conclusion, I just wanted to know what I was missing about the optimisation.
On Wednesday 20 September 2017 08:00 AM, Jonathan Nieder wrote:
Show 21 quoted lines
> From that link:
> for ( ;valid_int && *valid_int < 10; (*valid_int)++) {
> printf("Valid instance");
> }
>
> Both gcc and clang are able to optimize out the 'valid_int &&' because
> it is dereferenced on the RHS of the &&.
>
> For comparison, 'item < (list)->items + (list)->nr' does not
> dereference (list)->items. So that optimization doesn't apply here.
>
> A smart compiler could be able to take advantage of there being no
> object pointed to by a null pointer, which means
>
> item < (list)->items + (list)->nr
>
> is always false when (list)->items is NULL, which in turn makes a
> '(list)->items &&' test redundant. But a quick test with gcc 4.8.4
> -O2 finds that at least this compiler does not contain such an
> optimization. The overhead Michael Haggerty mentioned is real.
>I thought the compiler optimized that check out of the loop because the check was "invariant" across loop runs. IOW, the values used in the check didn't change across loop runs so the compiler thought it's better to do the check once outside the loop rather than doing it each time inside the loop. I guess this is some kind of "loop unswitching"[1]. I don't see how dereferencing influences the optimization here.
Just to be sure, I tried once more to see whether the compiler optimizes this or not. This time with a more similar example and even using the macro of concern. Surprisingly, the compiler did optimize the check out of the loop. This time both 'gcc' and 'clang' with an -O1 !
https://godbolt.org/g/Y6rHc1 https://godbolt.org/g/EMrftw
So, is the overhead still real or am I missing something?
[1] : https://en.wikipedia.org/wiki/Loop_unswitching
--- Kaartic