[PATCH] D29673: [DebugInfo] Append extended dereferencing mechanism to variables' DIExpression for targets that support more than one address space

Zhuravlyov, Konstantin via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 9 10:41:22 PST 2017


This is similar to what we have been thinking. I am working on updating the patch.


Thanks,

Konstantin

________________________________
From: David Blaikie <dblaikie at gmail.com>
Sent: Thursday, February 9, 2017 1:05:23 PM
To: reviews+D29673+public+09a34554c1cc6a77 at reviews.llvm.org; Zhuravlyov, Konstantin; Tye, Tony; Stellard, Thomas; aprantl at apple.com; Arsenault, Matthew
Cc: Chan, SiuChi; Purnomo, Budirijanto; Ding, Wei; nhaehnle at gmail.com; llvm-commits at lists.llvm.org
Subject: Re: [PATCH] D29673: [DebugInfo] Append extended dereferencing mechanism to variables' DIExpression for targets that support more than one address space

It sounds like there's probably a desire to have a target-specific mapping from LLVM address space to DWARF address space?

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

Matt - is that the kind of flexibility you'd like regarding remapping address spaces between LLVM and DWARF?

On Tue, Feb 7, 2017 at 2:38 PM Matt Arsenault via Phabricator <reviews at reviews.llvm.org<mailto:reviews at reviews.llvm.org>> wrote:
arsenm added a comment.

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


https://reviews.llvm.org/D29673



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170209/81b5b736/attachment.html>


More information about the llvm-commits mailing list