Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 13 Oct 2014 14:33:11 +0400, Ilya Verbin <iverbin@gmail.com> wrote:
> On 13 Oct 12:19, Jakub Jelinek wrote:
> > On Sat, Oct 11, 2014 at 06:49:00PM +0400, Ilya Verbin wrote:
> > > 2. -foffload-abi=[lp64|ilp32]
> > >    This option is supposed to tell mkoffload (and offload compiler) which ABI is
> > > used in streamed GIMPLE.  This option is desirable, because host and offload
> > > compilers must have the same ABI.  The option is generated by the host compiler
> > > automatically, it should not be specified by user.
> > 
> > But I'd like to understand why is this one needed.
> > Why should the compilers care?  Aggregates layout and alignment of
> > integral/floating types must match between host and offload compilers, sure,
> > but isn't that something streamed already in the LTO bytecode?
> > Or is LTO streamer not streaming some types like long_type_node?
> > I'd expect if host and offload compiler disagree on long type size that
> > you'd just use a different integral type with the same size as long on the
> > host.
> > Different sized pointers are of course a bigger problem, but can't you just
> > error out on that during reading of the LTO, or even handle it (just use
> > some integral type for when is the pointer stored in memory, and just
> > convert to pointer after reads from memory, and convert back before storing
> > to memory).  Erroring out during LTO streaming in sounds just fine to me
> > though.
> 
> Actually this option was developed by Bernd, so I think PTX team is going to use
> it somehow.  In MIC's case we're planning just to check in mkoffload that host
> and target compiler's ABI are the same.  Without this check we will crash in LTO
> streamer with ICE, so I'd like to issue an error message, rather than crashing.

In gcc/config/i386/intelmic-mkoffload.c, this option is now parsed to
initialize the target_ilp32 variable, which will then be used
(target_ilp32 ? "-m32" : "-m64") when invoking different tools.

In nvptx, we've been using the following approach:

--- gcc/config/nvptx/nvptx.h
+++ gcc/config/nvptx/nvptx.h
@@ -54,24 +54,28 @@
 
 /* Type Layout.  */
 
+#define TARGET_64BIT \
+  (flag_offload_abi == OFFLOAD_ABI_UNSET ? TARGET_ABI64 \
+   : flag_offload_abi == OFFLOAD_ABI_LP64 ? true : false)
+
 #define DEFAULT_SIGNED_CHAR 1
 
 #define SHORT_TYPE_SIZE 16
 #define INT_TYPE_SIZE 32
-#define LONG_TYPE_SIZE (TARGET_ABI64 ? 64 : 32)
+#define LONG_TYPE_SIZE (TARGET_64BIT ? 64 : 32)
 #define LONG_LONG_TYPE_SIZE 64
 #define FLOAT_TYPE_SIZE 32
 #define DOUBLE_TYPE_SIZE 64
 #define LONG_DOUBLE_TYPE_SIZE 64
 
 #undef SIZE_TYPE
-#define SIZE_TYPE (TARGET_ABI64 ? "long unsigned int" : "unsigned int")
+#define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "unsigned int")
 #undef PTRDIFF_TYPE
-#define PTRDIFF_TYPE (TARGET_ABI64 ? "long int" : "int")
+#define PTRDIFF_TYPE (TARGET_64BIT ? "long int" : "int")
 
-#define POINTER_SIZE (TARGET_ABI64 ? 64 : 32)
+#define POINTER_SIZE (TARGET_64BIT ? 64 : 32)
 
-#define Pmode (TARGET_ABI64 ? DImode : SImode)
+#define Pmode (TARGET_64BIT ? DImode : SImode)
 
 /* Registers.  Since ptx is a virtual target, we just define a few
    hard registers for special purposes and leave pseudos unallocated.  */

Should we settle on one of the two, that is, either pass -m[...] from
mkoffload, or handle flag_offload_abi in the respective backend?  I think
I prefer the intelmic-mkoffload.c approach; this seems cleaner to me:
mkoffload "configures" the offloading compiler.  (Also, the flag 32-bit
vs. 64-bit flag may in fact be needed for tools other than the offloading
compiler).  Bernd, is there any specific reason for the approach you had
chosen?


GrÃÃe,
 Thomas

Attachment: signature.asc
Description: PGP signature