<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Just FYI I feel this work could unblock the following issue:
<a href="https://bugs.llvm.org/show_bug.cgi?id=41730" class="OWAAutoLink">https://bugs.llvm.org/show_bug.cgi?id=41730</a><br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Anastasia Stulova via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 25 April 2019 07:39<br>
<b>To:</b> Bevin Hansson; clang-dev developer list<br>
<b>Cc:</b> nd<br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Improved address space conversion semantics for targets and language dialects</font>
<div> </div>
</div>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p style="margin-top:0; margin-bottom:0"><span>> So, I guess the current C/C++ behavior is according to spec if you think of all of the target ASes as disjoint (cannot implicitly convert, but all explicit conversion is allowed), but if we follow those rules
then there is no way for a target to prevent explicit casting between disjoint address spaces, which is pretty bad.</span></p>
<p style="margin-top:0; margin-bottom:0"><span><br>
</span></p>
<p style="margin-top:0; margin-bottom:0"><span>I would agree. We should probably make this more usable.</span></p>
<p style="margin-top:0; margin-bottom:0"><span><br>
</span></p>
<p style="margin-top:0; margin-bottom:0"><span><span>> Well, if the deduction lets us expand a template method with a given address space, then it becomes general. It would cause code duplication, but I think it's the only way to get any kind of decent performance
out of it. I'm not sure how having to do a target-specific address space check at runtime every time we want to access 'this' will work out.</span></span></p>
<p style="margin-top:0; margin-bottom:0"><span><span><br>
</span></span></p>
<p style="margin-top:0; margin-bottom:0">Yes, that's why I think evolution of HW to support the physical address translation<span><span> is the only way forward if we don't want to regress anything due to the use of address spaces. But in the mean time we could
workaround with code duplication. However, it is also not available option now. Generic address space would offer a complete solution at least in a short term and it can open paths to multiple better implementations in the future. We already have some address
space inference functionality available that can eliminate some of the horrible run-time overheads.</span></span></p>
<p style="margin-top:0; margin-bottom:0"><span><span><br>
</span></span></p>
<p style="margin-top:0; margin-bottom:0"><span><span>Anastasia<br>
</span></span></p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Bevin Hansson <bevin.hansson@ericsson.com><br>
<b>Sent:</b> 11 April 2019 10:26<br>
<b>To:</b> Anastasia Stulova; clang-dev developer list<br>
<b>Cc:</b> nd<br>
<b>Subject:</b> Re: [RFC] Improved address space conversion semantics for targets and language dialects</font>
<div> </div>
</div>
<div style="background-color:#FFFFFF">
<p><br>
</p>
<div class="x_x_moz-cite-prefix">On 2019-04-01 19:36, Anastasia Stulova wrote:<br>
</div>
<blockquote type="cite">
<div id="x_x_divtagdefaultwrapper" dir="ltr" style="">
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt"><font size="2"><span style="font-size:11pt">> There's nothing wrong with the type representation, it's simply that the C/C++ behavior cannot actually be captured with the superspace
model.</span></font> > In the current C/C++ model, the default behavior for address space conversions is that converting between any two address spaces implicitly is > always prohibited, but converting explicitly is always permitted. This cannot be expressed
in the superspace model, as there is no way to make > explicit conversion between AS1 and AS2 legal without also either making AS1->AS2 or AS2->AS1 implicitly legal, as 'isAddressSpaceOverlapping' is dependent on 'isAddressSpaceSuperSpaceOf'.
<br>
</span></font></p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt"><br>
</span></font></p>
<p style="margin-top:0; margin-bottom:0">I thought that this is because the address space support is incomplete. At least according to the embedded C report the casts to non-overlapping address spaces should be disallowed. It doesn't clarify however whether
it applies to both implicit and explicit cast.</p>
</div>
</blockquote>
<p>I believe that 'cast' in standardese means 'explicit cast'. I don't think implicit casts are ever referred to as casts, at least in the C standards. The Embedded-C report does make it clear separately that "If a pointer into address space A is assigned to
a pointer into a different address space B, a constraint requires that A be a subset of B.", which enshrines the implicit conversion rule.<br>
</p>
<p><br>
</p>
<p>In order to explicitly cast from an AS A to an AS B without invoking UB, one of the ASes must be a subset of the other (overlapping). Technically, E-C doesn't prohibit explicit casts where the ASes are disjoint (which matches the current 'generic' implementation
in Clang), but I'm of the opinion that this is a mistake. There is no reason to allow such casts as they *always* invoke UB.</p>
<p><br>
</p>
<p>So, I guess the current C/C++ behavior is according to spec if you think of all of the target ASes as disjoint (cannot implicitly convert, but all explicit conversion is allowed), but if we follow those rules then there is no way for a target to prevent
explicit casting between disjoint address spaces, which is pretty bad.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div id="x_x_divtagdefaultwrapper" dir="ltr" style="">
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt">> If it requires hardware or backend support it doesn't really feel like a logical concept any more. The overhead of the runtime checking also sounds a bit scary. I think that
if a target or language supports a generic address space, then they can use that for methods if they want to save on the typing overhead. Otherwise I think they'll just have to wait until there is a way to automatically deduce address space qualified member
functions at compile time.</span></font></p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt"><br>
</span></font></p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt">I think that the deduction won't help here because we would like the member functions to be called on objects in different address spaces, at least for the general case. And
then we end up with truly generic cases where multiple address spaces are to be used with the method on the place of generic. There are multiple ways to solve this problem including duplicating the methods but they don't seem to be ideal. I feel that the address
space support for C++ without something like generic address space can't be complete. I will start a separate RFC summarizing my thoughts with a few examples perhaps to avoid diverging the focus of this RFC.</span></font></p>
</div>
</blockquote>
<p>Well, if the deduction lets us expand a template method with a given address space, then it becomes general. It would cause code duplication, but I think it's the only way to get any kind of decent performance out of it. I'm not sure how having to do a target-specific
address space check at runtime every time we want to access 'this' will work out.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div id="x_x_divtagdefaultwrapper" dir="ltr" style="">
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt"><br>
</span></font></p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt">Thanks!</span></font></p>
<p style="margin-top:0; margin-bottom:0"><font size="2"><span style="font-size:11pt">Anastasia</span></font><br>
</p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Bevin Hansson
<a class="x_x_moz-txt-link-rfc2396E" href="mailto:bevin.hansson@ericsson.com"><bevin.hansson@ericsson.com></a><br>
<b>Sent:</b> 26 March 2019 18:18<br>
<b>To:</b> Anastasia Stulova; clang-dev developer list<br>
<b>Cc:</b> nd<br>
<b>Subject:</b> Re: [RFC] Improved address space conversion semantics for targets and language dialects</font>
<div> </div>
</div>
<div dir="ltr">
<div id="x_x_x_divtagdefaultwrapper" dir="ltr" style=""><br>
<div style="color:rgb(0,0,0)">
<div class="x_x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_x_PlainText"><br>
> Yes, I believe we might not have any upstream example for this and<br>
> hence current implementation is not complete. However, the current<br>
> approach has some sort of the guidelines on how the ambiguity can<br>
> be resolved that we would need to figure out with the new logic.<br>
<br>
> I guess we could use the implicit/explicit conversion for this, however<br>
> it might become more convoluted.<br>
<br>
Well, if we do change the interface to model conversion legality instead of superspaces, the functional behavior can be the same as today. We would just call the proper method for checking implicit AS conversion as we call isAddressSpaceSupersetOf today. However,
if we decide to change the overload behavior to consider shorter AS conversion paths over longer ones, the intuition might not be as obvious as it would be with the superspace approach.<br>
<br>
> I think there might be a little bit of that. For the developers from embedded<br>
> C or OpenCL background this concept is quite familiar. And one advantage<br>
> is that there is some sort of the spec that regulates the logic. I do find your<br>
> logic quite intuitive and for C++ at least we can definitely make bigger<br>
> changes. However, it also helps to build on top of something that already<br>
> works. I am only worried about covering the corner cases enough.<br>
<br>
> May be prototyping the solution you are suggesting is a good way forward.<br>
<br>
Yes, prototyping it is probably a good idea, at least to get an idea of how it could look in practice.<br>
<br>
<br>
> But this logic comes from C/C++, generally speaking I can't think of the case<br>
> where implicit conversion would be allowed between the types that won't be <br>
> explicitly convertible. I don't think there is anything OpenCL specific about this.<br>
> I think address space conversion logic is pretty much extending qualifiers in<br>
> C/C++. Do you think there is any use case that needs different logic? Then<br>
> perhaps we will have more work to do because qualifiers might not be the right<br>
> fit for the address spaces with such logic.<br>
<br>
<font size="2"><span style="font-size:11pt">There's nothing wrong with the type representation, it's simply that the C/C++ behavior cannot actually be captured with the superspace model.</span></font> In the current C/C++ model, the default behavior for address
space conversions is that converting between any two address spaces implicitly is always prohibited, but converting explicitly is always permitted. This cannot be expressed in the superspace model, as there is no way to make explicit conversion between AS1
and AS2 legal without also either making AS1->AS2 or AS2->AS1 implicitly legal, as 'isAddressSpaceOverlapping' is dependent on 'isAddressSpaceSuperSpaceOf'. This is the reason why the conversion logic in checkAddressSpaceCast is hidden behind the OpenCL option,
for example.<br>
<br>
<br>
> Generic AS would have to be preserved in the LLVM IR too and then it can<br>
> be lowered by the backed. The best solution would be to add some special HW<br>
> support to allow translating address spaces efficiently. However it can be<br>
> emulated by the compiler but then a toolchain should provide some way to<br>
> detect in what specific AS an object in generic AS points to. This can be done<br>
> by adding special intrinsics. However this checks are quite costly. There is some<br>
> help for reducing the overheads of generic address space provided in LLVM already<br>
> in form of a special pass that allows to infer the specific address space where<br>
> applicable.<br>
<br>
If it requires hardware or backend support it doesn't really feel like a logical concept any more. The overhead of the runtime checking also sounds a bit scary. I think that if a target or language supports a generic address space, then they can use that for
methods if they want to save on the typing overhead. Otherwise I think they'll just have to wait until there is a way to automatically deduce address space qualified member functions at compile time.<br>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>