Hi Jakub! On Tue, 4 Dec 2018 14:13:49 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Sun, Nov 11, 2018 at 10:31:42PM -0600, Thomas Schwinge wrote: > > On Tue, 28 Feb 2017 18:43:36 +0100, I wrote: > > > The 2.5 versions of the OpenACC standard added a new chapter "Profiling > > > Interface". > > > > I'd like to get that into trunk. It's not yet complete (that is, doesn't > > provide all the information specified), but it's very useful already, and > > the missing pieces can later be added incrementally. > > > > Jakub, would you please especially review the non-OpenACC-specific > > changes here, including the libgomp ABI changes? > > > > (Note that this patch doesn't apply on top of trunk. I extracted it out > > of openacc-gcc-8-branch, plus additional changes, and it depends on a > > number of other pending patches. Due to the many regions of code > > touched, there are a lot of "textual" conflicts when porting it to > > current trunk, but the "structure" will be the same.) > > Seems rather expensive to me, especially with the dependence on > libbacktrace and the unconditional initialization of the profiling from the > library constructor. Could e.g. libbacktrace or some libgomp plugin that is > linked against libbacktrace be dlopened only when apps ask for this stuff?
Thanks, that seems plausible, and I'm looking into that. > OpenMP 5 has a profiling API too (OMPT) (... which I'm not familiar with...) > there the rough plan for when it > will be implemented is that libgomp as the library will implement only the > absolute required minimum and perhaps have a variant library that is a > replacement for libgomp if more detailed instrumentation is needed. The "problem" with the OpenACC Profiling Interface is that the user can enable the callbacks etc. anytime dynamically at run time. So, as I understand, that rules out the "variant library" approach? Grüße Thomas
