[ltt-dev] [PATCH] fix the "unknown" case
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Tue Jun 15 10:57:12 EDT 2010
On Tue, Jun 15, 2010 at 10:52:23AM +0200, Paolo Bonzini wrote:
> On 06/14/2010 08:25 PM, Paul E. McKenney wrote:
> >>Anyway, a simple configure test is to compile this with -fdump-rtl-expand:
> >>
> >> int
> >> f()
> >> {
> >> __sync_synchronize();
> >> }
> >>
> >>If the assembly output includes "__sync_synchronize", or the dump
> >>file includes the text "unspec:BLK", it should be fine. In
> >>particular, ia64, mips, and Alpha are ok. Else you can use the
> >>pthreads trick. I can try to make a patch if you're interested.
> >>Or, more simply, it's possible to hardcode the above three platforms
> >>since it's unlikely that others will be added soon.
> >
> >And I attached the input file, the .expand file, and the .s file.
> >
> >I see neither __sync_synchronize in the .s file nor "unspec" in the
> >.expand file. Or was I confused about what to look for?
>
> No, the __sync_synchronize instruction is optimized out. I think
> I'll make GCC 4.6+ give a warning.
Thank you for looking into this!
Hmmm... One mistake I made last time was to forget the "-mcpu=cortex-a9
-mtune=cortex-a9" -- but adding this does not change the result.
If I have other code in the function, I do get the following in
the .s file:
@ 10 "gcc_sync.c" 1
#__sync_synchronize
But still no meaningful code.
So for the moment I am using my own asm to generate a dmb instruction.
Which raises the question as to whether I can really trust the other
__sync_ instructions. They -seem- to be working for me, but one cannot
prove them correct by testing. :-(
Thanx, Paul
More information about the lttng-dev
mailing list