<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 2019-04-25 08:39, Anastasia Stulova wrote:<br>
</div>
<blockquote type="cite" cite="mid:DB6PR0802MB261416886EB3E1AB05403BC6F03D0@DB6PR0802MB2614.eurprd08.prod.outlook.com">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<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"><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>
</div>
</blockquote>
<p>It's a noble goal, but I think evolving the hardware isn't necessarily an option for everyone...</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>In any case, should I submit a patch with the changes mentioned in the RFC and we can move forward from there? I guess we don't necessarily agree on how the validity of conversions should be expressed, but I don't see how to make the solution fully configurable
by both targets and languages while keeping the overlap model.</p>
<p><br>
</p>
<p>/ Bevin<br>
</p>
<br>
</body>
</html>