[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.

Finkel, Hal J. via cfe-dev cfe-dev at lists.llvm.org
Thu Jan 17 10:35:28 PST 2019


On 1/17/19 12:10 PM, Alexey Bataev wrote:


-------------
Best regards,
Alexey Bataev

17.01.2019 12:58, Finkel, Hal J. пишет:


On 1/17/19 11:19 AM, Alexey Bataev wrote:

Just one question: how are you going to emit the type if it is not supported by the device?

If you going to emit it as just the array of bytes, I don't think this is the right solution.


We don't need to do this. At the IR level, we can support all IR-level types regardless of target. I don't see this as a problem. I'll point out, however, that if we don't support this, you'll be asking the user to do exactly this (i.e., figure out what bytes to put in a structure to make it layout compatible with another structure with the problematic type). Choosing between the user doing this and the compiler doing this, the compiler should do it.


Yes, we can do this at the IR level. But can we translate it correctly to the real device data?


User classes/datatypes with the unsupported data types are just not mappable types and, thus, cannot be used on the device at all. In any form. Even with the unified memory.


This is just wrong. These types, especially with unified memory, should be accessible from the device. If we have problem emitting operations on those types, then we should restrict errors to uses of those specific operations. Remember, I'm talking about uses of pointers to types containing the problematic types, not direct uses of the problematic types themselves. When you say that such pointer types are not usable in any form, please provide a rationale for this assertion. These are implementation-defined types, and we should define them to make them the most useful for our users.


This is exactly the definition of the bad design. You're going to put to the unified memory piece of data, that can be used only on the host. Do you really want to do this? Maybe, we'd better to help user to design its program properly and use unified memory/mapping only when it is really necessary?


Our goal is to accelerate applications, not to redesign those applications around the restrictions we decide to impose in our implementation of OpenMP. Is this situation ideal? No. But what you propose seems worse.


What you're proposing is that no data structure which we can access on the accelerator might have a pointer to any other structure, transitively, that has a long-double data member (or __float128 or whatever). That's awful. Is it ideal that we won't be able to operate on those data members on the device? No, of course not. But the probability of that being a problem is much smaller than taking large parts of an application's class hierarchy and banning its use, wholesale, in device-generated code.


Thanks again,
Hal



Thanks again,

Hal


-------------
Best regards,
Alexey Bataev

17.01.2019 12:15, Doerfert, Johannes Rudolf пишет:

> The compiler does not know anything about the layout on the host when it compiles for the device.


Just a side note: I'll try to write up an RFC next week to propose a conceptual change in our compilation process that makes this argument go away.



________________________________
From: Alexey Bataev <a.bataev at outlook.com><mailto:a.bataev at outlook.com>
Sent: Thursday, January 17, 2019 11:11:55 AM
To: Finkel, Hal J.
Cc: John McCall; Reid Kleckner; Artem Belevich; Justin Lebar; Richard Smith; cfe-dev; John McCall; Doerfert, Johannes Rudolf
Subject: Re: [cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.


The compiler does not know anything about the layout on the host when it compiles for the device. We cannot do anything with the types that are not supported by the target device and we cannot use the layout from the host. And it is user responsibility to write and use the code that is compatible with the the target devices.

He/she does not need to use macros/void* types, there are templates.

You cannot use classes, which use types incompatible with the device. There is a problem with the data layout on the device and we just don't know how to represent such classes on the device.

-------------
Best regards,
Alexey Bataev

17.01.2019 11:47, Finkel, Hal J. пишет:

On 1/17/19 9:52 AM, Alexey Bataev wrote:


Because the type is not compatible with the target device.


But it's not that simple. The situation is that the programming
environment supports the type, but *operations* on that type are not
supported in certain contexts (e.g., when compiled for a certain
device). As you point out, we already need to move in this explicit
direction by, for example, allowing typedefs for types that are not
supported in all contexts, function declarations, and so on. In the end,
we should allow our users to design their classes and abstractions using
good software-engineering practice without worrying about access-context
partitioning.

Also, the other problem here is that the function I used as an example
is a very common C++ idiom. There are a lot of classes with function
that return a reference to themselves. Classes can have lots of data
members, and those members might not be accessed on the device (even if
the class itself might be accessed on the device). We're moving to a
world in which unified memory is common - the promise of this technology
is that configuration data and complex data structures, which might be
occasionally accessed (but for which explicitly managing data movement
is not performance relevant) are handled transparently. If use of these
data structures is transitively poisoned by use of any type not
supported on the device (including by pointers to types that use those
types), then we'll force unhelpful and technically-unnecessary
refactoring, thus reducing the value of the feature.

In the current implementation we pre-process the source twice, and so we
can:

 1. Use ifdefs to change the data memebers when compiling for different
targets. This is hard to get right because, in order to keep the data
layout otherwise the same, the user needs to understand the layout rules
in order to put something in the structure that is supported on the
target and keeps the layout the same (this is very error prone). Also,
if we move to a single-preprocessing-stage model, this no longer works.

 2. Replace all pointers to relevant types with void*, or similar, and
use a lot of casts. This is also bad.

We shouldn't be forcing users to play these games. The compiler knows
the layout on the host and it can use it on the target. The fact that
some operations on some types might not be supported on the target is
not relevant to handling pointers/references to containing types.

Thanks again,

Hal




-------------
Best regards,
Alexey Bataev

17.01.2019 10:50, Finkel, Hal J. пишет:


On 1/17/19 9:27 AM, Alexey Bataev wrote:


It should be compilable for the device only iff function foo is not used
on the device.


Says whom? I disagree. This function should work on the device. Why
should it not?

 -Hal




-------------
Best regards,
Alexey Bataev

17.01.2019 10:24, Finkel, Hal J. пишет:


On 1/17/19 4:05 AM, Alexey Bataev wrote:


Best regards,
Alexey Bataev



17 янв. 2019 г., в 0:46, Finkel, Hal J. <hfinkel at anl.gov><mailto:hfinkel at anl.gov> написал(а):




On 1/16/19 8:45 AM, Alexey Bataev wrote:

Yes, I thought about this. But we need to delay the diagnostic until
the Codegen phase. What I need is the way to associate the diagnostic
with the function so that this diagnostic is available in CodeGen.

Also, we need to postpone the diagnotics not only for functions,
but,for example, for some types. For example, __float128 type is not
supported by CUDA. We can get error messages when we ran into
something like `typedef __float128 SomeOtherType` (say, in some system
header files) and get the error diagnostic when we compile for the
device. Though, actually, this type is not used in the device code,
the diagnostic is still emitted and we need to delay too and emit it
only iff the type is used in the device code.



This should be fixed for CUDA too, right?

Also, we still get to have pointers to aggregates containing those types
on the device, right?



No, why? This is not allowed and should be diagnosed too. If somebody tries somehow to use not allowed type for the device variables/functions - it should be diagnosed.


Because this should be allowed. If I have:

struct X {
  int a;
  __float128 b;
};

and we have some function which does this:

X *foo(X *x) {
  return x;
}

We'll certainly want this function to compile for all targets, even if
there's no __float128 support on some accelerator. The whole model only
really makes sense if the accelerator shares the aggregate-layout rules
of the host, and this is a needless hassle for users if this causes an
error (especially in a unified-memory environment where configuration
data structures, etc. are shared between devices).

Thanks again,

Hal




Thanks again,

Hal




-------------
Best regards,
Alexey Bataev
15.01.2019 17:33, John McCall пишет:


On 15 Jan 2019, at 17:20, Alexey Bataev wrote:
This is not only for asm, we need to delay all target-specific
diagnostics.
I'm not saying that we need to move the host diagnostic, only the
diagnostic for the device compilation.
As for Cuda, it is a little but different. In Cuda the programmer
must explicitly mark the device functions,  while in OpenMP it must
be done implicitly. Thus, we cannot reuse the solution used for Cuda.


All it means is that you can't just use the solution used for CUDA
"off the shelf".  The basic idea of associating diagnostics with the
current function and then emitting those diagnostics later when you
realize that you have to emit that function is still completely
applicable.

John.


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory



--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190117/bfe3bad7/attachment-0001.html>


More information about the cfe-dev mailing list