drop -aux{dir,base}, revamp -dump{dir,base}

Tobias Burnus tobias@codesourcery.com
Thu Jun 18 09:41:40 GMT 2020


On 6/18/20 8:10 AM, Alexandre Oliva wrote:
> Could you possibly give this *completely* untested patch a try and let
> me know whether it does any good?

gcc/lto-wrapper.c:1473:41: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
     incoming_dumppfx = dumppfx = option->arg;
                                          ^
gcc/lto-wrapper.c:1518:10: warning: ISO C++ forbids converting a string constant to 'char*' [-Wpedantic]
   dumppfx = "a.";

gcc/config/nvptx/mkoffload.c:535:13: error: invalid conversion from 'const char*' to 'char*'
      dumppfx = outname;
              ^

Otherwise, see attachment. I now added also the @/tmp file which is
passed to mkoffload.

> I actually thought it might be appropriate to use ".x<offload_target>"
> instead of ".target" in the dumpbase passed to mkoffload, so that we
> create different file names for different offload targets,

I wonder whether we need to do this – as one can create code for
multiple offload targets by the same compiler at the same time.
I don't know how common this is in practice, but the compilers
offered by the Linux distributions support this.
(At least Debian and SUSE, I did not follow whether
Red Hat/Fedora already has GCN enabled or not.)

For example, on an openSUSE Linux system, one gets with
"gcc -fopenmp hello-world.f90 -v 2>&1|grep '/mkoffload":
/usr/lib64/gcc/x86_64-suse-linux/10//accel/nvptx-none/mkoffload @/tmp/ccKJReG8
/usr/lib64/gcc/x86_64-suse-linux/10//accel/amdgcn-amdhsa/mkoffload @/tmp/ccJcfKw8

Thus, without the offload_target prefix, they would dump into the same file!

On the other hand, by using -foffload=<name> one can restrict
the code to the host ("disable") or a list of offload devices,
typically the two above, although GCC also supports HSA (works differently)
and intelmic.

Thus, if really needed for debugging, one would be still able to
save the dump one wants to have.

I think the OpenACC libgomp testsuite cycles through the
available offload targets (disable, ...). While OpenMP
simply uses those which are available – which can be
zero/host (e.g. if build w/o offload support), one or
multiple.

> but then, how
> do we access that target name in the testsuite machinery to pass
> ".x<offload_target>.mkoffload" as the dump base suffix appended to the
> source/output basename?

Good question.

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.log
Type: text/x-log
Size: 1636 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200618/4fd423fb/attachment-0002.bin>
-------------- next part --------------
-save-temps
-v
-xlto
-m64
-save-temps
-v
./nvptx-merged-loop.o
-fno-openmp
-fno-pie
-foffload-abi=lp64
-O2
-fno-diagnostics-show-caret
-fopenacc
-fdiagnostics-color=never
-fno-diagnostics-show-caret
-dumpbase
./nvptx-merged-loop..target
-fdump-rtl-mach
-v
-fdump-rtl-mach
-v
-dumpdir
""
-dumpbase
./nvptx-merged-loop..target.mkoffload
-dumpbase-ext
""
-o
./nvptx-merged-loop..target.mkoffload
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run.log
Type: text/x-log
Size: 45235 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200618/4fd423fb/attachment-0003.bin>


More information about the Gcc-patches mailing list