[Openmp-dev] Enabling OMPT by default

Tue Dec 19 14:51:11 PST 2017

Is there a significant barrier to building both OMPT=on and OMPT=off
binaries and LD_PRELOAD-ing the former when the user actually wants it?
This is basically what happens with Linux packages that don't have debug
symbols by default (and users who want them have to install the dbg
package) and some MPI libraries.

Jeff

On Tue, Dec 19, 2017 at 1:22 PM, Joachim Protze via Openmp-dev <
openmp-dev at lists.llvm.org> wrote:

> Ok, this seems to be similar as for x86. You can add multiple offset
> prints. The test will match any of these printed addresses.
>
> - Joachim
>
>
> On 12/19/2017 09:36 PM, Paul Osmialowski wrote:
>
>> Yeah, you're right initializing this variable to zero fixes failing test
>> case. However, this uncovers flaw in my snippet. Some test cases have
>> failed as additional str instruction was added after nop:
>>
>>      libomp :: ompt/misc/control_tool.c
>>      libomp :: ompt/synchronization/taskwait.c
>>      libomp :: ompt/synchronization/test_lock.c
>>      libomp :: ompt/synchronization/test_nest_lock_parallel.c
>>
>> Will look at this later as I'm waiting for my flitht now.
>>
>> On 19/12/2017 19:51, Joachim Protze wrote:
>>
>>> Probably my fault, there is an uninitialized use of "condition":
>>>
>>> https://github.com/llvm-mirror/openmp/blob/master/runtime/
>>> test/ompt/parallel/nested_lwt.c#L11
>>>
>>> Please initialize to 0 and test again.
>>>
>>> Thanks
>>> Joachim
>>>
>>>
>>> On 12/19/2017 03:15 PM, Paul Osmialowski via Openmp-dev wrote:
>>>
>>>> Nah, it blocks forever on nested_lwt.c when I started it on 96-cores
>>>> ARMv8.1 machine. BTW, the missing part of callbacks.h for tests I added
>>>> like this:
>>>>
>>>> diff --git a/runtime/test/ompt/callback.h b/runtime/test/ompt/callback.h
>>>> index 8481fb4..9a560aa 100755
>>>> --- a/runtime/test/ompt/callback.h
>>>> +++ b/runtime/test/ompt/callback.h
>>>> @@ -105,6 +105,11 @@ ompt_label_##id:
>>>>   #define print_possible_return_addresses(addr) \
>>>>     printf("%" PRIu64 ": current_address=%p\n",
>>>> ompt_get_thread_data()->value, \
>>>>            ((char *)addr) - 8)
>>>> +#elif KMP_ARCH_AARCH64
>>>> +// On AArch64 the NOP instruction is 4 bytes long.
>>>> +#define print_possible_return_addresses(addr) \
>>>> +  printf("%" PRIu64 ": current_address=%p\n",
>>>> ompt_get_thread_data()->value, \
>>>> +         ((char *)addr) - 4)
>>>>   #else
>>>>   #error Unsupported target architecture, cannot determine address
>>>> offset!
>>>>   #endif
>>>>
>>>> On 18/12/2017 13:56, Jonas Hahnfeld via Openmp-dev wrote:
>>>>
>>>>> Does it pass the tests? I doubt that because it needs modifications as
>>>>> Joachim pointed out (had to do the same for PPC64).
>>>>>
>>>>> Jonas
>>>>>
>>>>> Am 2017-12-18 14:52, schrieb Pawel Osmialowski:
>>>>>
>>>>>> Guys,
>>>>>>
>>>>>> For more than a year I was always building libomp with
>>>>>> -DLIBOMP_OMPT_SUPPORT=ON for our AArch64 machines and I'd happily see
>>>>>> it enabled by default.
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> On Mon, 2017-12-18 at 14:23 +0100, Jonas Hahnfeld wrote:
>>>>>>
>>>>>>> Adding Paul, maybe he can help here. Though switching the default
>>>>>>> for
>>>>>>> x86/x86_64 and ppc64 doesn't mean it has to work on AArch64 for the
>>>>>>> 6.0
>>>>>>> release, it will just stay deactivated as for MIPS(64).
>>>>>>>
>>>>>>> Jonas
>>>>>>>
>>>>>>> Am 2017-12-18 13:02, schrieb Cownie, James H via Openmp-dev:
>>>>>>> > The ARM folks should chip in. This should clearly be tested on
>>>>>>> > AARCH64
>>>>>>> > as well!
>>>>>>> >
>>>>>>> > -- Jim
>>>>>>> >
>>>>>>> > Jim Cownie <james.h.cownie at intel.com>
>>>>>>> > SSG/DPD/TCAR (Technical Computing, Analyzers, and Runtimes)
>>>>>>> > Tel: +44 117 9071438
>>>>>>> >
>>>>>>> > -----Original Message-----
>>>>>>> > From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On
>>>>>>> > Behalf
>>>>>>> > Of Joachim Protze via Openmp-dev
>>>>>>> > Sent: Monday, December 18, 2017 11:58 AM
>>>>>>> > To: Openmp-dev <openmp-dev at lists.llvm.org>
>>>>>>> > Subject: [Openmp-dev] Enabling OMPT by default
>>>>>>> >
>>>>>>> > Dear all,
>>>>>>> >
>>>>>>> > OpenMP 5.0 will introduce OMPT, the OpenMP tools interface. The
>>>>>>> > current
>>>>>>> > implementation in the LLVM/OpenMP runtime is at the level of
>>>>>>> > OpenMP
>>>>>>> > TR6,
>>>>>>> > as published in November (with some known issues, were we have
>>>>>>> > patches
>>>>>>> > under review).
>>>>>>> > Currently, this feature is deactivated by default
>>>>>>> > (LIBOMP_OMPT_SUPPORT).
>>>>>>> > According to overhead measurements performed by Intel and on some
>>>>>>> > of
>>>>>>> > our
>>>>>>> > machines, this feature introduces a worst case runtime overhead of
>>>>>>> > ~4%,
>>>>>>> > but for most cases basically no overhead.
>>>>>>> > As I understood, some of the build-bots run the tests when the
>>>>>>> > feature
>>>>>>> > is enabled. We locally test the changes continuously with different
>>>>>>> > compiler versions (icc/gcc/clang), but only on x86_64 architecture.
>>>>>>> > Further, this feature was tested on ppc64.
>>>>>>> >
>>>>>>> > How should we proceed to enable this feature by default, and get it
>>>>>>> > tested on other architectures?
>>>>>>> > For the 6.0 release, I would like to enable OMPT at least for the
>>>>>>> > supported platforms x86/x86_64 and ppc64.
>>>>>>> >
>>>>>>> >
>>>>>>> > We would also appreciate collaboration with vendors/users of other
>>>>>>> > platforms, to ensure the code is running there.
>>>>>>> >
>>>>>>> > Typically, only the architecture specific offset needs to be added:
>>>>>>> > https://github.com/llvm-mirror/openmp/blob/master/runtime/
>>>>>>> test/ompt
>>>>>>> > /callback.h#L95
>>>>>>> >
>>>>>>> > Looking forward to your feedback,
>>>>>>> >
>>>>>>> > Joachim
>>>>>>> > _______________________________________________
>>>>>>> > Openmp-dev mailing list
>>>>>>> > Openmp-dev at lists.llvm.org
>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>>>>>> > -----------------------------------------------------------------
>>>>>>> > ----
>>>>>>> > Intel Corporation (UK) Limited
>>>>>>> > Registered No. 1134945 (England)
>>>>>>> > Registered Office: Pipers Way, Swindon SN3 1RJ
>>>>>>> > VAT No: 860 2173 47
>>>>>>> >
>>>>>>> > This e-mail and any attachments may contain confidential material
>>>>>>> > for
>>>>>>> > the sole use of the intended recipient(s). Any review or
>>>>>>> > distribution
>>>>>>> > by others is strictly prohibited. If you are not the intended
>>>>>>> > recipient, please contact the sender and delete all copies.
>>>>>>> > _______________________________________________
>>>>>>> > Openmp-dev mailing list
>>>>>>> > Openmp-dev at lists.llvm.org
>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>>>>>>
>>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>>>>> confidential and may also be privileged. If you are not the intended
>>>>>> recipient, please notify the sender immediately and do not disclose
>>>>>> the contents to any other person, use it for any purpose, or store or
>>>>>> copy the information in any medium. Thank you.
>>>>>>
>>>>> _______________________________________________
>>>>> Openmp-dev mailing list
>>>>> Openmp-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>>>>
>>>> _______________________________________________
>>>> Openmp-dev mailing list
>>>> Openmp-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>>>
>>>
>>>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20171219/102f5f6b/attachment-0001.html>