Hi!
I'm highly annoyed that we're wasting a lot of time arguing about such a
minor item.
On Mon, 27 May 2019 21:29:13 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, May 27, 2019 at 09:05:06PM +0200, Thomas Schwinge wrote:
> > > The arrays are emitted in the *.omplower dump, so I think it is much
> > > better
> > > to scan-tree-dump their content
> >
> > That's not feasible in the general case.
>
> Why? The arrays have easily parseable names (.omp_data_kinds.N), then they
> have an initializer and you can easily write a regexp to say match 3
> occurences of the firstprivate int kind constant in there.
Given the test case that's part of my patch, we get:
$ grep -F omp_data_kinds < lower_omp_target-mappings-1.c.007t.omplower
.omp_data_kinds.15[0] = D.2509;
.omp_data_kinds.15[1] = 781;
.omp_data_kinds.15[2] = 525;
#pragma omp target num_teams(1) thread_limit(0)
map(from:*vla.1[0] [len: _18]) map(firstprivate:vla [pointer assign, bias: 0])
firstprivate(D.2437) firstprivate(argc) [child fn: main._omp_fn.0
(.omp_data_arr.13, .omp_data_sizes.14, .omp_data_kinds.15)]
.omp_data_kinds.15 = {CLOBBER};
#pragma omp target num_teams(1) thread_limit(0)
map(from:argc [len: 4]) map(tofrom:*vla.1 [len: D.2440]) map(firstprivate:vla
[pointer assign, bias: 0]) map(alloc:MEM[(char *)argv] [len: 0])
map(firstprivate:argv [pointer assign, bias: 0]) [child fn: main._omp_fn.1
(.omp_data_arr.18, .omp_data_sizes.19, .omp_data_kinds.20)]
#pragma omp target num_teams(1) thread_limit(0)
is_device_ptr(argv) map(tofrom:*vla.1 [len: D.2440]) map(firstprivate:vla
[pointer assign, bias: 0]) firstprivate(argc) [child fn: main._omp_fn.2
(.omp_data_arr.25, .omp_data_sizes.26, .omp_data_kinds.27)]
So that doesn't even display all the arrays. (The (default) 'static'
ones appear only in the next, 'lower', dump.)
What OMP construct does '.omp_data_kinds.15' relate to? I can't tell
(what number each one gets), so can have just one per file?
What is 'D.2509'? I can't follow/scan for that.
The values '781', '525' contain the alignment encoded, which may vary per
GCC target configuration, making it clumsy to scan for.
Etc.
(Why do I even have to explain this to you -- you must aleady before have
come across such dumps, and their peculiarities?)
With my patch, we can instead have:
// { dg-final { scan-tree-dump-times {(?n)^Mapping
\[.*lower_omp_target-mappings-1.c:8:9\] main\._omp_fn\.0 \[0\] '\*vla.1\[0\]':
kind = 2/15, size = .*, align = 1$} 1 omplower } }
// { dg-final { scan-tree-dump-times {(?n)^Mapping
\[.*lower_omp_target-mappings-1.c:8:9\] main\._omp_fn\.0 \[1\] '.*': kind = 13,
size = 0, align = 4$} 1 omplower { target { ! { c++ && lp64 } } } } }
// { dg-final { scan-tree-dump-times {(?n)^Mapping
\[.*lower_omp_target-mappings-1.c:8:9\] main\._omp_fn\.0 \[1\] '.*': kind = 13,
size = 0, align = 8$} 1 omplower { target { c++ && lp64 } } } }
// { dg-final { scan-tree-dump-times {(?n)^Mapping
\[.*lower_omp_target-mappings-1.c:8:9\] main\._omp_fn\.0 \[2\] 'argc': kind =
13, size = 0, align = 4$} 1 omplower } }
> > > if for whatever reason adding a runtime
> > > testcase isn't sufficient
> >
> > Why should I have an execution test for something that should really be
> > verified at the compiler side, at compile time? And, for example, an
>
> Generally a runtime test can check all compilation phases, linking, runtime,
> while what looks like a unit test only tests a small portion of that.
I don't understand what you're intending to explain here.
> > > over adding further printouts and matching that.
> >
> > I had assumed that you'd noticed that a lot of compiler passes are
> > dumping stuff that can then be scanned for. Are you insisting that GCC's
>
> Usually the detailed messages in the dump print why certain changes are
> done, or other information that is not readily available in the dump
> already.
So we must not do something new/useful, because it's... new?
> I'm not convinced what you are doing brings anything that isn't
> there already.
Aha.
Why exactly are you objecting that the compiler produces useful
intermediate dumps, understandable my machine and human?
Grüße
Thomas
