public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Bernd Schmidt <bernds@codesourcery.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Ilya Verbin <iverbin@gmail.com>
Subject: Re: nvptx offloading patches [3/n], RFD
Date: Mon, 03 Nov 2014 22:28:00 -0000	[thread overview]
Message-ID: <5458016A.4080109@redhat.com> (raw)
In-Reply-To: <5454CAB9.3040907@codesourcery.com>

On 11/01/14 05:57, Bernd Schmidt wrote:
> This is not against current trunk; it applies to gomp-4_0-branch where
> it is one of the necessary parts to make offloading x86->nvptx work. The
> issue is that the LTO file format depends on the machine_modes enum, it
> needs to match between host and offload target. The easiest way to do
> this is to just use the host-modes.def when compiling an offload compiler.
>
> Ports that want to be hosts for offloading may need to modify their
> modes.def. The patch below contains changes to i386-modes.def which
> modifies XFmode depending on a target switch. I'm not actually entirely
> sure what to do about this. Do we want to make this flag an error when
> offloading is enabled? Or maybe add float format support to the
> -foffload-abi option?
>
> Thoughts? Ok for the first part of the patch once the other offloading
> patches have gone in (bootstrapped and tested on x86_64-linux)?
It feels like we've got another real distinction to make.  We've had 
host, build & target and they're all independent.  It feels like we need 
offload target and better separate between target and offload target. 
Then we need to figure out the places where we've got bleed-out.

Not sure how to deal with this any further out than the immediate term 
than using a hack like this. Though I'd prefer to avoid the #ifdef as it 
seems to me this shouldn't be baked in at build/configure time.

jeff

  reply	other threads:[~2014-11-03 22:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01 11:58 Bernd Schmidt
2014-11-03 22:28 ` Jeff Law [this message]
2014-11-04 12:38   ` nvptx offloading patches [3/n], i386 bits RFD Bernd Schmidt
2014-11-04 18:58     ` Uros Bizjak
2014-11-04 21:50     ` Jeff Law
2014-11-05  0:23       ` Bernd Schmidt
2014-11-14 18:42         ` Bernd Schmidt
2015-02-04 11:38 ` nvptx offloading patches [3/n], RFD Jakub Jelinek
2015-02-09 10:20   ` Richard Biener
2015-02-16 21:08     ` Jakub Jelinek
2015-02-16 21:35       ` Richard Biener
2015-02-16 21:44         ` Jakub Jelinek
2015-02-17 10:00           ` Richard Biener
2015-02-18 10:00             ` Jakub Jelinek
2015-02-25  8:51               ` Patch ping Jakub Jelinek
2015-02-25  9:30                 ` Richard Biener
2015-02-25 16:51                   ` Jakub Jelinek
2015-02-18  9:05           ` nvptx offloading patches [3/n], RFD Thomas Schwinge
2015-02-17 13:32       ` Ilya Verbin
2015-02-17 15:39         ` Jakub Jelinek
2015-02-17 16:21           ` Joseph Myers
2015-02-17 16:40             ` Jakub Jelinek
2015-02-18  9:12               ` Thomas Schwinge
2015-02-18 10:27                 ` Jakub Jelinek
2015-02-18 11:34                 ` Jakub Jelinek
2015-02-18 12:10                   ` Thomas Schwinge
2015-02-18 12:35                     ` Jakub Jelinek
2015-02-19 10:50                       ` If we're building an offloading compiler, always enable the LTO front end (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-19 10:53                         ` Jakub Jelinek
2015-02-20  9:42                           ` Thomas Schwinge
2015-02-19 10:20               ` nvptx offloading patches [3/n], RFD Bernd Schmidt
2015-02-19 12:02                 ` Offloading compilers' support libraries (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-19 12:11                   ` Offloading compilers' support libraries Bernd Schmidt
2015-02-19 12:19                     ` Thomas Schwinge
2015-02-20 15:35                       ` Ilya Verbin
2015-02-20 19:59                         ` Ilya Verbin
2015-02-26 19:35                           ` Ilya Verbin
2015-02-20  9:33                 ` Offloading compilers' libgcc installation (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-20 19:32                   ` Ilya Verbin
2015-03-10 12:35                     ` Offloading compilers' libgcc installation Thomas Schwinge
2015-04-27 16:15                       ` Thomas Schwinge
2015-04-27 16:16                         ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5458016A.4080109@redhat.com \
    --to=law@redhat.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iverbin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).