[squid-dev] Fwd: [PATCH] for loops modernization

[khaled belhout]

thank you guys for the feedback.
also the tool can do an amazing job about static analysis and diagnostics.
i want to use the tool for null pointer propagation and null pointer
dereference diagnostics.
but we need to annotate the some functions with [[noreturn]] attribute like :
void fatal(const char *message);
void fatalf(const char *fmt,...);
void fatal_dump(const char *message);
void xassert(const char *msg, const char *file, int line);
but i hit a problem with xassert
the function was defined in two places with two different behaviors.
the first one in : compat/assert.cc
print the error massage and never return
the second one in: src/debug.cc
print the debug massage ,never return if shutting_down flag is clear
and return if shutting_down flag is set!
isn't that an ODR rule violation!
Thank you,
khaled.

2017-03-16 6:34 GMT+01:00 Amos Jeffries <squid3 at treenet.co.nz>:
> On 16/03/2017 3:43 a.m., Adam Majer wrote:
>> On 03/15/2017 03:17 PM, Amos Jeffries wrote:
>>> Theoretically range-for loops should allow multi-threaded CPU to run
>>> those loops a bit faster. If that can be demonstrated using a tool like
>>> polygraph you have a good argument for a patch containing that change to
>>> go in as a pure performance change.
>>
>> No. That would break many many things. There are special directives that
>> allow this to happen with things like OpenMPI compilers, but that's not
>> what we are talking about here.
>>
>> And theoretically, if you blindly allow compilers to optimize loops like
>> that, you are just as likely to introduce hardware stalls that will
>> result in slower execution of the overall loop. The only way to look at
>> these,
>>
>>     for (TYPE _i : _c )
>>
>> is syntactic sugar.
>>
>>
>> Best regards,
>> - Adam
>>
>> PS. And if you are talking about vertorization of these loops, that
>> already happens with regular loops. See,
>>
>>     https://gcc.gnu.org/projects/tree-ssa/vectorization.html
>
> I mean tricks like compiler with CPU-specific knowledge being able to
> emit assembly that helps pre-fetch the address pointers for all objects
> in the container, and/or if it can prove the objects are read-only can
> have hyper-threads pre-load the container contents into L1/L2 cache in
> time for the main thread to run the business logic faster without much
> loading delays.
>
> AFAIK the range-for does allow certain code flow guarantees (like
> full-length container iteration) being known without any analysis. So
> not completely syntactic sugar. Yes compiler could do the same with
> traditional loops, but only after extra analysis which might be turned off.
>
> I'm not sure if thus would have any visible effect at all. We might be
> unlucky in that these things are not supportable, or the data sizes
> Squid handles blow the benefits away. Thus the request for proof.
>
> Amos
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev