<div dir="ltr">It sounds like there's probably a desire to have a target-specific mapping from LLVM address space to DWARF address space?<br><br>If that's the case, then maybe that target specific hook could also inform the consumer about the default (ie: instead of adding the targetSupportsMultipleAddressSpaces hook, have: Optional<unsigned> getDwarfAddressSpace(unsigned LLVMAddressSpace) - that way the default can be "None" and any implementation that wants to provide address spaces can communicate the "default" of its choosing by returning None in that case and whatever non-None values it wants in other cases))<br><br>Matt - is that the kind of flexibility you'd like regarding remapping address spaces between LLVM and DWARF?<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 7, 2017 at 2:38 PM Matt Arsenault via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">arsenm added a comment.<br class="gmail_msg">
<br class="gmail_msg">
It would also be good if we could leave open the possibility of decoupling LLVM address space 0 from OpenCL private address space. I would like to be able to someday be able to change that<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D29673" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29673</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>