Offload configurations (was: [patch] New backend header reduction)

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]

Hi!

On Fri, 30 Oct 2015 15:31:26 -0600, Jeff Law <law@redhat.com> wrote:
> On 10/30/2015 02:23 PM, Cesar Philippidis wrote:
> > On 10/30/2015 01:20 PM, Andrew MacLeod wrote:
> >> On 10/30/2015 02:09 PM, Andrew MacLeod wrote:
> >>> On 10/30/2015 01:56 PM, Cesar Philippidis wrote:
> >>>> On 10/23/2015 12:24 PM, Jeff Law wrote:
> >>>>> On 10/23/2015 10:53 AM, Andrew MacLeod wrote:
> >>>>>
> >>>> There's a little bit of fallout with this patch when building an
> >>>> offloaded compiler for openacc. It looks like cgraph.c needs to include
> >>>> context.h and varpool.c needs context.h and omp-low.h. There's a couple
> >>>> of ifdef ENABLE_OFFLOADING which may have gone undetected with your
> >>>> script.
> >>> If they are defined on the command line or some other way I couldn't
> >>> see with the targets I built, then that is the common case when that
> >>> happens.  I don't think I did any openacc builds.     OR maybe I need
> >>> to add nvptx to my coverage builds. Perhaps that is best.
> >>>> I've bootstrapped the attached patch for an nvptx/x86_64-linux target.
> >>>> I'm still testing that toolchain. If the testing comes back clean, is
> >>>> this patch OK for trunk?
> >> Ah, I see.  there is no nvptx target in config-list.mk, so it never got
> >> covered.

(Now there is, but that's not actually the problem here.)

> > Yeah, you need to build two separate compilers. Thomas posted some
> > directions here <https://gcc.gnu.org/wiki/Offloading>. You could
> > probably reproduce it with openmp and Intel's MIC emulation target too.
> Oh, there's something specific to the offloading support that needs 
> context.h, it's not the ptx port.  Duh.  Anyway, it'd still be good to 
> get standard builds of the nvptx backend into config-list.mk.
> 
> Not sure how painful it'd be to add the offloading path.

Shouldn't actually be difficult: you ought (untested) to be able to
configure with, for example,
--enable-offload-targets=nvptx-none,x86_64-intelmicemul-linux-gnu even if
not actually having built these offloading compilers.  (Due to a
"strange" requirement of Intel MIC offloading configuration, that "the
GCC build reference[s]/depend[s] on the Intel MIC offloading compiler's
installation directory (which [thus has to be] built and installed
earlier)",
<http://news.gmane.org/find-root.php?message_id=%3C878uaq68fn.fsf%40kepler.schwinge.homeip.net%3E>,
this would fail later on, but as config-list.mk testing only builds the
"all-gcc" target, that's not a problem.)

So, maybe add to config-list.mk one x86_64-linux-gnu target with
--enable-offload-targets=[...] to cover code guarded by the
ENABLE_OFFLOADING preprocessor conditional.  And, maybe add one
nvptx-none or x86_64-intelmic-linux-gnu target with
--enable-as-accelerator-for=[something] to cover code guarded by the
ACCEL_COMPILER preprocessor conditional.

> This is a great example of why we're trying to minimize/eliminate 
> conditional compilation :-)

Agreed.  For the longer term, I think we should get rid of the (only)
handful of ENABLE_OFFLOADING and ACCEL_COMPILER preprocessor
conditionals.  For the former we'll have to find something, but the
latter could just be replaced with "if (flag_offload_abi !=
OFFLOAD_ABI_UNSET)" or similar, I think.


Grüße
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]