[PATCH] Decouple creation of CodeGenTypes from CodeGenModule.

Mark Lacey mark.lacey at apple.com
Thu Oct 10 16:15:21 PDT 2013


I’ve decided to table this for now after running into issues decoupling CGCXXABI and CodeGenModule. Without being able to separate the creation of those, this patch has limited impact.

Mark

On Oct 9, 2013, at 9:53 PM, Mark Lacey <mark.lacey at apple.com> wrote:

> Does anyone have any further feedback on this patch, and if not does it look good to go in?
> 
> Thanks,
> 
> Mark
> 
> On Oct 8, 2013, at 8:42 PM, Mark Lacey <mark.lacey at apple.com> wrote:
> 
>> Hi David,
>> 
>> On Oct 8, 2013, at 6:33 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> 
>>> To any particular end? (is there a need for this - I could imagine it's just convenient to implement the way it is now)
>> 
>> Yes - I have been planning on sending something to cfe-dev once I had more to talk about. In the meantime I have been preparing and sending a few small changes that seem like generally good changes on their own, and that also help with a larger change I am investigating.
>> 
>> I am looking at exposing ABI information for use in LLDB. One example of where this would be useful would be for ‘thread step-out’ (aka finish). When you do a step-out, it currently attempts to display the returned value, but this is all hard-coded in LLDB for each platform, and has limits on at least some of them in terms of what is supported. The idea is to expose enough about how Clang types are mapped to LLVM types, and then how LLVM types are mapped to actual locations (registers or memory) according to the ABI, to make it simple for LLDB to support this kind of functionality more completely with less effort and less chance of disagreement between the generated code and where LLDB thinks things live.
>> 
>> The current tight coupling between CodeGenModule, CodeGenTypes, and ABIInfo has made it difficult to make progress experimenting with different ways of exposing interfaces that could be used by LLDB to get from Clang types to LLVM types (the last two really are mutually dependent at this point, and there does not seem to be an easy way around that or substantial benefit in trying to separate out their creation right now).
>> 
>> Thanks,
>> 
>> Mark
>> 
>> 
>>> 
>>> 
>>> On Tue, Oct 8, 2013 at 5:45 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>>> Hi -
>>> 
>>> Please review and let me know if you have any feedback.
>>> 
>>> Thanks,
>>> 
>>> Mark
>>> 
>>> ----------------
>>> 
>>> 
>>> Currently the only way to create a CodeGenTypes class is to pass it a
>>> CodeGenModule, which is primarily used to initialize the members of
>>> CodeGenTypes, but is also used in a couple of places to gain access to a
>>> few members of CodeGenModule (OpenCLRuntime, DebugInfo,
>>> and TargetCodeGenInfo).
>>> 
>>> This change makes it possible to construct a CodeGenTypes class
>>> independently of a CodeGenModule. The constructor to CodeGenTypes is
>>> updated to explicitly have parameters for each of its members, and new
>>> pointer members are added for the information that was being referenced
>>> from CodeGenModule.
>>> ---
>>> lib/CodeGen/CGCall.cpp        |   2 +-
>>> lib/CodeGen/CodeGenModule.cpp |  12 +++--
>>> lib/CodeGen/CodeGenTypes.cpp  |  24 ++++++----
>>> lib/CodeGen/CodeGenTypes.h    |  28 +++++++++--
>>> lib/CodeGen/TargetInfo.cpp    | 106 ++++++++++++++++++++++++------------------
>>> 5 files changed, 111 insertions(+), 61 deletions(-)
>>> 
>>> 
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> 
>>> 
>> 
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131010/17d67b4b/attachment.html>


More information about the cfe-commits mailing list