GCC: OpenMP posix pthread

2012-02-19 Thread Erotavlas_turbo 
Hi,

I'm starting to use Helgrind a tool of Valgrind. I read on the manual the 
following statement:
Runtime support library for GNU OpenMP (part of GCC), at least for GCC versions 
4.2 and 4.3. The GNU OpenMP runtime library (libgomp.so) constructs its own 
synchronisation primitives using combinations of atomic memory instructions and 
the futex syscall, which causes total chaos since in Helgrind since it cannot 
"see" those.

In the latest version of GCC, is this still true or now the OpenMP uses the 
standard POSIX pthread?

Thank you

Re: GCC: OpenMP posix pthread

2012-02-19 Thread Tim Prince 

On 2/19/2012 9:42 AM, erotavlas_tu...@libero.it wrote:


I'm starting to use Helgrind a tool of Valgrind. I read on the manual the 
following statement:
Runtime support library for GNU OpenMP (part of GCC), at least for GCC versions 4.2 and 
4.3. The GNU OpenMP runtime library (libgomp.so) constructs its own synchronisation 
primitives using combinations of atomic memory instructions and the futex syscall, which 
causes total chaos since in Helgrind since it cannot "see" those.

In the latest version of GCC, is this still true or now the OpenMP uses the 
standard POSIX pthread?



Do you have a specific OS family in mind?


--
Tim Prince

Re: GCC: OpenMP posix pthread

2012-02-19 Thread Erotavlas_turbo 
> On 2/19/2012 9:42 AM, erotavlas_tu...@libero.it wrote:
>
> > I'm starting to use Helgrind a tool of Valgrind. I read on the manual the 
> > following statement:
> > Runtime support library for GNU OpenMP (part of GCC), at least for GCC 
> > versions 4.2 and 4.3. The GNU OpenMP runtime library (libgomp.so) 
> > constructs its own synchronisation primitives using combinations of atomic 
> > memory instructions and the futex syscall, which causes total chaos since 
> > in Helgrind since it cannot "see" those.
> >
> > In the latest version of GCC, is this still true or now the OpenMP uses the 
> > standard POSIX pthread?
> >
>
> Do you have a specific OS family in mind?
>
>
> --
> Tim Prince
>

Yes, I'm talking about the UNIX OS (Linux, MacOSx). The tool valgrind is only 
available for these systems.


Salvatore Frandina

[i386] Question about Constraint Modifier character in smaxdf3 pattern.

2012-02-19 Thread Kumar, Venkataramanan 
Hi all,

Sphinx3 benchmark segmented when built and ran with -Ofast and 
-fprefecth-loop-arrays.

When I debugged the benchmark executable, found that it is caused due to 
register swapping happening 
at reload  for the smaxdf3 pattern.

197r.ira
-
(insn 457 456 458 28 (set (reg:DF 687)
(smax:DF (reg/v:DF 367 [ dval1 ])
(reg/v:DF 154 [ dval1 ]))) eval.c:58 914 {smaxdf3}
 (expr_list:REG_DEAD (reg/v:DF 367 [ dval1 ])
(expr_list:REG_DEAD (reg/v:DF 154 [ dval1 ])
(nil
198.reload
---
(insn 457 456 458 28 (set (reg:DF 21 xmm0 [687])
(smax:DF (reg/v:DF 21 xmm0 [orig:154 dval1 ] [154])
(reg/v:DF 51 xmm14 [orig:367 dval1 ] [367]))) eval.c:58 914 
{smaxdf3}
 (nil))

In my case the register 367 is sNAN. 

MAXSD instruction is sensitive to sNAN and is not commutative.

DEST[63-0]  IF (DEST[63-0] == SNaN) THEN SRC[63-0];
ELSE IF SRC[63-0] == SNaN) THEN SRC[63-0];
ELSE IF (DEST[63-0] > SRC[63-0]) 
THEN DEST[63-0] 
ELSE SRC[63-0]; 
FI;

So I think the commutative % should be removed from the pattern when -Ofast 
(fastmath) is set.

Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 184372)
+++ gcc/config/i386/i386.md (working copy)
@@ -16507,7 +16507,7 @@
 (define_insn "3"
   [(set (match_operand:MODEF 0 "register_operand" "=x,x")
(smaxmin:MODEF
- (match_operand:MODEF 1 "nonimmediate_operand" "%0,x")
+ (match_operand:MODEF 1 "nonimmediate_operand" "0,x")
  (match_operand:MODEF 2 "nonimmediate_operand" "xm,xm")))]
   "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
   "@

This solved the sphinx segmentation.  But the comments on i386.md says the 
commutative % mark is correct.
Please provide your opinion.

Regards,
Venkat

Re: [i386] Question about Constraint Modifier character in smaxdf3 pattern.

2012-02-19 Thread Marc Glisse 

On Sun, 19 Feb 2012, Kumar, Venkataramanan wrote:


Sphinx3 benchmark segmented when built and ran with -Ofast and 
-fprefecth-loop-arrays.

[...]

In my case the register 367 is sNAN.


-Ofast implies -ffast-math which implies -ffinite-math-only:
Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.

so I am not sure what you expect exactly.

--
Marc Glisse