[llvm-commits] [cfe-commits] [Patch] Move TargetData from Target to Support/VMCore

[Chandler Carruth]

On Thu, Oct 4, 2012 at 4:03 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote:

>  ** **
>
> ** **
>
> *From:* Chandler Carruth [mailto:chandlerc at google.com]
> *Sent:* Thursday, October 04, 2012 3:56 PM
> *To:* Villmow, Micah
> *Cc:* Kim Gräsman; Evan Cheng; llvm-commits at cs.uiuc.edu LLVM; Nadav
> Rotem; cfe-commits at cs.uiuc.edu cfe
>
> *Subject:* Re: [cfe-commits] [llvm-commits] [Patch] Move TargetData from
> Target to Support/VMCore****
>
>  ** **
>
> On Thu, Oct 4, 2012 at 3:51 PM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:****
>
>  I'm curious how this could work.****
>
>  ****
>
> I have two classes.****
>
> TargetData and DataLayout.****
>
>  ****
>
> I want to point all uses of TargetData at DataLayout.****
>
>  ****
>
> typedef won't work not just because of forward declarations, but also
> because of static functions.****
>
>  ****
>
> So, I could define DataLayout as a subclass of TargetData, but once I want
> to move to DataLayout, how do I define TargetData in a way that won't
> require changes to many many locations.****
>
>  ** **
>
> I think you need to reverse the suggestion and instead use:****
>
> ** **
>
> class TargetData {****
>
>   // existing code****
>
> };****
>
> ** **
>
> class DataLayout : public TargetData {****
>
>   // some forwarding boilerplate****
>
> }****
>
> ** **
>
> Then you can change everyone to refer to DataLayout, and then lift the
> implementation of TargetData up into DataLayout.****
>
> ** **
>
> You'll have to change folks to refer to DataLayout in o "top-down" way --
> producers first.****
>
> *[Villmow, Micah] This is a good suggestion, but I was actually thinking
> of doing it in the reverse. Turn TargetData into the forwarding
> boilerplate, but I just wanted to make sure this was the intention instead
> of moving forward and having to redo some work.*
>
> **
>

The reason I suggest this direction is because it seems slightly easier to
update the producers first, and the consumers second. But that's subjective.


> * *
>
> *What subprojects do I need to modify?*
>
> *Clang/LLVM/compiler-RT I know*
>
> * *
>
> *Others would be LLDB, dragonegg, vmkit?*
>
> * *
>
> *What about libc++/polly/klee/safecode, etc...?*
>

LLDB, dragonegg, vmkit, klee, safecode, and polly seem the likel suspects.
But some searching will help here. ;]


> **
>
> * **Basically what is the line that separates which projects need to be
> updated by myself and what needs to be updated by their owners?*
>

The ones checked into llvm-projects SVN tree should be updated by you where
possible.

The ones with build bots as well definitely need to be updated. The only
ones of your set without build bots are vmkit, klee, and safecode.

For the ones with build bots, I think it's fine to essentially
speculatively fix them. The bots will complain if something goes wrong.



> * *
>
> *Thanks,*
>
> *Micah*
>
> ** **
>
> ** **
>
>   ****
>
> Micah****
>
>  ****
>
> *From:* Kim Gräsman [mailto:kim.grasman at gmail.com]
> *Sent:* Thursday, October 04, 2012 1:33 PM
> *To:* Villmow, Micah
> *Cc:* Chris Lattner; Evan Cheng; llvm-commits at cs.uiuc.edu LLVM;
> cfe-commits at cs.uiuc.edu cfe; Nadav Rotem****
>
>
> *Subject:* Re: [cfe-commits] [llvm-commits] [Patch] Move TargetData from
> Target to Support/VMCore****
>
>  ****
>
> HI Micah,****
>
>
>
> On Thursday, October 4, 2012, Villmow, Micah wrote:****
>
> Chris, the problem with steps #2/#3 is that plenty of clients have forward
> declarations of TargetData and the typedef won't work in this case, so I
> need to update the clients anyways.****
>
>  ****
>
> One trick I've used as an alternative to typedefs is to just derive from
> the old class, e.g.****
>
>  ****
>
>   class NewName : public TargetData {};****
>
>  ****
>
> This is forward-declarable just as well as TargetData itself.****
>
>  ****
>
> FWIW,****
>
> - Kim****
>
>
> _______________________________________________
> 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/llvm-commits/attachments/20121004/21e169d2/attachment.html>