[cfe-dev] [RFC] Improved address space conversion semantics for targets and language dialects

[Bevin Hansson via cfe-dev]

On 2019-04-25 08:39, Anastasia Stulova wrote:

> 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.


I would agree. We should probably make this more usable.


> 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.


Yes, that's why I think evolution of HW to support the physical address translation 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.

It's a noble goal, but I think evolving the hardware isn't necessarily an option for everyone...




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.


/ Bevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190508/d2740243/attachment.html>