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

[Lang Hames]

Hi Jim,

I wanted to verify target data strings during bitcode/asm parsing. I think
the logical place for TargetData verification is in TargetData itself, but
it would violate layering to have VMCore depend on that. Instead VMCore has
it's own hacky target-data string parsers (see for instance
llvm::Module::getPointerSize()).

I think the solution to my problem is to formalize what constitutes IR
representable target-specific information, and decide where that should
live. I didn't tackle that at the time because I had limited experience
with IR level passes/infrastructure. The question seems closely related to
the issues Micah and Hal have raised, and Nadav's BoF would be an excellent
forum to discuss it.

Cheers,
Lang.


On Thu, Sep 27, 2012 at 1:53 PM, Jim Grosbach <grosbach at apple.com> wrote:

> Lang,
>
> If I recall correctly, you looked at something similar to this before. Can
> you elaborate a bit on the obstacles you encountered?
>
> -Jim
>
> On Sep 27, 2012, at 9:42 AM, "Villmow, Micah" <Micah.Villmow at amd.com>
> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Hal Finkel [mailto:hfinkel at anl.gov]
> >> Sent: Wednesday, September 26, 2012 9:40 PM
> >> To: Evan Cheng
> >> Cc: Villmow, Micah; llvm-commits at cs.uiuc.edu LLVM; Nadav Rotem; cfe-
> >> commits at cs.uiuc.edu cfe; Christopher Lattner
> >> Subject: Re: [cfe-commits] [llvm-commits] [Patch] Move TargetData from
> >> Target to Support/VMCore
> >>
> >> On Wed, 26 Sep 2012 21:18:24 -0700
> >> Evan Cheng <evan.cheng at apple.com> wrote:
> >>
> >>>
> >>>
> >>> On Sep 26, 2012, at 11:07 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >>>
> >>>> On Tue, 25 Sep 2012 16:16:22 -0700
> >>>> Evan Cheng <evan.cheng at apple.com> wrote:
> >>>>
> >>>>> Sorry, I understand why you are requesting this but I thinking
> >>>>> moving TargetData to support is conceptually dirty.
> >>>>
> >>>> Can you please explain this? I think that the opposite is true:
> >>>> Having TargetData in Target is conceptually dirty. TargetData
> >>>> represents 'target information that is available to frontends and
> >>>> IR-level passes without linking to the target descriptions'.
> >>>
> >>> Agreed.
> >>>
> >>>> As a result, I feel
> >>>> that TargetData does not belong with the target-description
> >>>> infrastructure, and so it should be moved out of Target so that
> >>>> everyone can use it.
> >>>
> >>> I agree it should be moved out but at least it's target related.
> >>> Polluting Support / VMCore with it is just worse. They have nothing to
> >>> do with target data conceptually.
> >>
> >> Good point. On the other hand, TargetData is specified along with the
> >> core IR language reference. Perhaps the problem really is that auto-
> >> upgrade support is in VMCore, and auto-upgrade is full of logic that
> >> deals with target-specific intrinsics (and, maybe soon, pointer size
> >> information). Maybe making a libTargetData would be better?
> > [Villmow, Micah] Targetdata itself is just an in memory representation of
> > the target string that is stored in the module. So the information is in
> > VMCore, why not the way to access that information?
> >>
> >> -Hal
> >>
> >>> This is all a matter of taste.
> >>> I'll let Chris make the decision.
> >>>
> >>> Evan
> >>>
> >>>>
> >>>>> Nadav is going to
> >>>>> propose a BOF at the DevMeeting to talk about designing an
> >>>>> abstraction to expose target information to LLVM ir.
> >>>>
> >>>> Great!
> >>>>
> >>>> Thanks again,
> >>>> Hal
> >>>>
> >>>>> Can we hold off
> >>>>> this kind of change for now?
> >>>>>
> >>>>> Losing the ability to verify isn't a strong enough argument for an
> >>>>> immediate change. I don't follow the auto-upgrade argument. Can you
> >>>>> elaborate?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Evan
> >>>>>
> >>>>> On Sep 21, 2012, at 4:08 PM, "Villmow, Micah"
> >>>>> <Micah.Villmow at amd.com> wrote:
> >>>>>
> >>>>>> This time with the actual patch
> >>>>>>
> >>>>>> From: Villmow, Micah
> >>>>>> Sent: Friday, September 21, 2012 4:08 PM
> >>>>>> To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu
> >>>>>> Subject: [Patch] Move TargetData from Target to Support/VMCore
> >>>>>>
> >>>>>> I have attached a patch which moves TargetData from Target to
> >>>>>> Support/VMCore. The reason why I would like to have this change
> >>>>>> can be read about in more detail in message [1][2], which in turn
> >>>>>> is required for [3]. In short, I need the capability of querying,
> >>>>>> if available, target specific information in the bitcode during
> >>>>>> verifier and the auto-upgrade mechanism. Because TargetData is in
> >>>>>> the target directory, a circular dependency is created when the
> >>>>>> verifier and auto-upgrade mechanism utilize the information.
> >>>>>> Please let me know what you think and if this approach isn't good,
> >>>>>> possible alternate solutions, Micah
> >>>>>>
> >>>>>> [1]
> >>>>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.h
> >>>>>> tml
> >>>>>> [2]
> >>>>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053166.h
> >>>>>> tml
> >>>>>> [3]
> >>>>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052639.html
> >>>>>> <move_target_data_to_support_vmcore.txt>__________________________
> >>>>>> _____________________ llvm-commits mailing list
> >>>>>> llvm-commits at cs.uiuc.edu
> >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Hal Finkel
> >>>> Postdoctoral Appointee
> >>>> Leadership Computing Facility
> >>>> Argonne National Laboratory
> >>
> >>
> >>
> >> --
> >> Hal Finkel
> >> Postdoctoral Appointee
> >> Leadership Computing Facility
> >> Argonne National Laboratory
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120927/902d7939/attachment.html>