On 10/05/16 11:24, Andrew Haley wrote:
> On 09/05/16 22:40, Tom Udale wrote:
>
>> My confusion is whether or not the memory cobberer prevents movement of
>> statements in addition to flushing any values that may be in registers
>> before the compiler_barrier() line. i.e. it is unclear if there is any
>> control over what statements the memory being flushed is attached to (if
>> this makes any sense).
>
> Memory barriers only prevent code which accesses memory from being
> moved.
>
> It's not going to be easy to do what you're asking for in the
> presence of optimization. GCC orders instruction generation by
> dependency. I'd simply put all the code you want to time into a
> separate function in a separate compilation unit and do this:
>
> start = starttime(); foo(); end = endtime();
>
> Alteratively, it might be possible to define asm inputs and outputs
> so that your asm barriers depend on the statements you're trying
> to measure.
>
> Andrew.
>
An easy way is to make sure your "do some stuff" has at least one thing
that it depends on, and at least one result. You can even make the
dependencies completely artificial. But the key is to make this bits
volatile:
volatile unsigned ct;
volatile unsigned time;
volatile unsigned v1;
volatile unsigned v2;
{
ct = CNT;
v2 = doSomeStuff(v1);
time = CNT - ct;
}
You can also use inline assembly to force dependency calculations:
// Ensure that "val" has been calculated before next volatile access
// by requiring it as an assembly input. Note that only volatiles are
ordered!
#define forceDependency(val) \
asm volatile("" :: "" (val) : )
