This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/n] OpenMP 4.0 offloading infrastructure: libgomp


On Tue, Oct 07, 2014 at 05:51:53PM +0400, Ilya Verbin wrote:
> On 07 Oct 15:06, Jakub Jelinek wrote:
> > Still have issues with the non-installed testing.
> 
> The idea was that the offload compiler should be installed.
> 
> > If I add
> > -B /usr/src/gcc-git/objinst/usr/local/lib/gcc/x86_64-pc-linux-gnu/5.0.0/ \
> > -B /usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/
> 
> Yes, since lto-wrapper uses COMPILER_PATH + "/accel/<target>/" to find
> mkoffload, it requires that the offload compiler with mkoffload are installed.
> Probably, it can be extended to search in the build paths, specified by
> --enable-offload-targets option.
> 
> > to the command line so it at least finds mkoffload, it then can't find for
> > some reason the offload compiler:
> 
> mkoffload itself also wants the offload compiler with correct name
> (<host>-accel-<target>-gcc).  It can be extended to use xgcc.  But I don't know,
> how to construct all paths for it (-B, -I, -L)?
> 
> > So, what exactly should be added (by libgomp.exp) so that the testing succeeds in
> > the case of non-installed offload and non-installed host compilers?
> 
> Looks like, that non-installed offload compiler requires some complications.
> Is this really necessary?

I think it is useful, doesn't have to be in the initial checkin, but I'd
certainly prefer if from the (optional) --enable-offload-target argument
it would figure out everything it needs to add for testing.
And, if mkoffload isn't flexible enough to be convinced to find it in that
scenario, it better should be made more flexible.

Another thing I've noticed, when target-1.exe is built, there are tons of
sections that IMHO should have been stripped away:

  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000400238 000238 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            0000000000400254 000254 000020 00   A  0   0  4
  [ 3] .hash             HASH            0000000000400278 000278 000094 04   A  4   0  8
  [ 4] .dynsym           DYNSYM          0000000000400310 000310 0001b0 18   A  5   1  8
  [ 5] .dynstr           STRTAB          00000000004004c0 0004c0 000189 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          000000000040064a 00064a 000024 02   A  4   0  2
  [ 7] .gnu.version_r    VERNEED         0000000000400670 000670 000070 00   A  5   2  8
  [ 8] .rela.dyn         RELA            00000000004006e0 0006e0 000018 18   A  4   0  8
  [ 9] .rela.plt         RELA            00000000004006f8 0006f8 000150 18   A  4  11  8
  [10] .init             PROGBITS        0000000000400848 000848 00001a 00  AX  0   0  4
  [11] .plt              PROGBITS        0000000000400870 000870 0000f0 10  AX  0   0 16
  [12] .text             PROGBITS        0000000000400960 000960 000b44 00  AX  0   0 16
  [13] .fini             PROGBITS        00000000004014a4 0014a4 000009 00  AX  0   0  4
  [14] .rodata           PROGBITS        00000000004014b0 0014b0 000020 00   A  0   0  8
  [15] .eh_frame_hdr     PROGBITS        00000000004014d0 0014d0 000094 00   A  0   0  4
  [16] .eh_frame         PROGBITS        0000000000401568 001568 00032c 00   A  0   0  8
  [17] .init_array       INIT_ARRAY      0000000000601dd8 001dd8 000010 00  WA  0   0  8
  [18] .fini_array       FINI_ARRAY      0000000000601de8 001de8 000008 00  WA  0   0  8
  [19] .jcr              PROGBITS        0000000000601df0 001df0 000008 00  WA  0   0  8
  [20] .dynamic          DYNAMIC         0000000000601df8 001df8 000200 10  WA  5   0  8
  [21] .got              PROGBITS        0000000000601ff8 001ff8 000008 08  WA  0   0  8
  [22] .got.plt          PROGBITS        0000000000602000 002000 000088 08  WA  0   0  8
  [23] .data             PROGBITS        00000000006020a0 0020a0 000120 00  WA  0   0 32
  [24] .offload_image_section PROGBITS        00000000006021c0 0021c0 003439 00  WA  0   0 16
  [25] __gnu_offload_funcs PROGBITS        0000000000605600 005600 000018 00  WA  0   0  8
  [26] __gnu_offload_vars PROGBITS        0000000000605618 005618 000010 00  WA  0   0  8
  [27] .bss              NOBITS          0000000000605628 005628 000008 00  WA  0   0  4
  [28] .comment          PROGBITS        0000000000000000 005628 000055 01  MS  0   0  1
  [29] .gnu.target_lto_.profile.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 00567d 000014 00      0   0  1
  [30] .gnu.target_lto_.jmpfuncs.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 005691 000028 00      0   0  1
  [31] .gnu.target_lto_.inline.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 0056b9 000130 00      0   0  1
  [32] .gnu.target_lto_.pureconst.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 0057e9 00001d 00      0   0  1
  [33] .gnu.target_lto_fn2._omp_fn.1.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 005806 0005fc 00      0   0  1
  [34] .gnu.target_lto_fn2._omp_fn.0.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 005e02 000765 00      0   0  1
  [35] .gnu.target_lto_fn3._omp_fn.3.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 006567 0005a7 00      0   0  1
  [36] .gnu.target_lto_fn3._omp_fn.2.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 006b0e 000435 00      0   0  1
  [37] .gnu.target_lto_fn4._omp_fn.5.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 006f43 00066b 00      0   0  1
  [38] .gnu.target_lto_fn4._omp_fn.4.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 0075ae 0004fc 00      0   0  1
  [39] .gnu.target_lto_tgt.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 007aaa 000160 00      0   0  1
  [40] .gnu.target_lto_.symbol_nodes.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 007c0a 0000fe 00      0   0  1
  [41] .gnu.target_lto_.refs.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 007d08 00002c 00      0   0  1
  [42] .gnu.target_lto_.offload_table.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 007d34 000017 00      0   0  1
  [43] .gnu.target_lto_.decls.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 007d4b 000a77 00      0   0  1
  [44] .gnu.target_lto_.symtab.3e3ce5aae4e95dd4 PROGBITS        0000000000000000 0087c2 000027 00      0   0  1
  [45] .gnu.target_lto_.opts PROGBITS        0000000000000000 0087e9 000083 00      0   0  1
  [46] .shstrtab         STRTAB          0000000000000000 00886c 000405 00      0   0  1
  [47] .symtab           SYMTAB          0000000000000000 0098b8 000cc0 18     48  91  8
  [48] .strtab           STRTAB          0000000000000000 00a578 0005f5 00      0   0  1

I thought .gnu.target_lto* sections hold LTO bytecore and are desirable only in the
ET_REL objects for ld(1)/lto-wrapper purposes.  For large programs containing large
target regions the LTO bytecode could be very big, so leaving it in the binary is
undesirable.

For .offload_image_section name, wouldn't it be better to prefix that with .gnu?
And, is __gnu_offload_{funcs,vars} named that way just because the plugin isn't able to add
symbols around the sections for you?  As it doesn't contain a dot, it would collide
with user declarations put into __attribute__((section ("__gnu_offload_funcs"))).

Looking at the symbols:

    73: 0000000000605618    16 OBJECT  LOCAL  DEFAULT   26 .omp_var_table
    74: 0000000000605600    24 OBJECT  LOCAL  DEFAULT   25 .omp_func_table
    78: 00000000006055f9     0 NOTYPE  LOCAL  DEFAULT   24 _offload_image_intelmic_end
    79: 00000000006021d0     0 NOTYPE  LOCAL  DEFAULT   24 _offload_image_intelmic_start
   102: 0000000000605600     0 OBJECT  GLOBAL HIDDEN    25 _omp_func_table
   118: 00000000006021a0     0 OBJECT  GLOBAL HIDDEN    23 __OPENMP_TARGET__
   124: 00000000006021c0    16 OBJECT  GLOBAL HIDDEN    24 __OPENMP_TARGET_DATA__
   130: 0000000000605628     0 OBJECT  GLOBAL HIDDEN    26 _omp_vars_end
   133: 0000000000605618     0 OBJECT  GLOBAL HIDDEN    25 _omp_funcs_end
   135: 0000000000605618     0 OBJECT  GLOBAL HIDDEN    26 _omp_var_table

perhaps it would be better to have . somewhere in the names too, though if you are
accessing that from C or declaring them in C, it might be too hard to bother.
It is all in reserved namespace anyway, but use two underscores prefix instead of one
for those IMHO.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]