[Openmp-dev] Enabling OMPT by default

Wed Dec 20 01:27:30 PST 2017

Banana Pi M64 comes with 64bit arm. They are ~100 €/$. Probably, Jonas can
set up the testing once he is back😀

-Joachim

Am 20.12.2017 10:16 schrieb "Cownie, James H via Openmp-dev" <
openmp-dev at lists.llvm.org>:

> > I think we don't have access to an ARM machine to test ourselves
> There was someone on Twitter the other day running OpenMP code on his
> Raspberry Pi (using "Raspbian",
> I assume since he had a Linux environment) so it may be possible to add
> ARM to your testing environment
> at little monetary cost. (Of course the time cost to get it all working
> may be non-trivial, but the
>  hardware cost seems under 100Euro).
>
> That would be a 32bit ARM, not AARCH64, but still better than nothing.
>
> -- 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
> Jonas Hahnfeld via Openmp-dev
> Sent: Tuesday, December 19, 2017 6:52 PM
> To: Paul Osmialowski <pawel.osmialowski at foss.arm.com>
> Cc: openmp-dev at lists.llvm.org
> Subject: Re: [Openmp-dev] Enabling OMPT by default
>
> Am 2017-12-19 15:15, schrieb Paul Osmialowski:
> > Nah, it blocks forever on nested_lwt.c when I started it on 96-cores
> > ARMv8.1 machine.
>
> Can you get us a stack trace? I think we don't have access to an ARM
> machine to test ourselves but we might be able to guess based on the
> implementation.
>
> > 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
>
> Interesting that we don't have a load instruction at all for AArch64.
> Sigh, that's why we have to customize it for every architecture...
>
> >
> > 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
> ---------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20171220/affebd6b/attachment-0001.html>