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 <[email protected]> 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" <[email protected]> > wrote: > > > > > > >> -----Original Message----- > >> From: Hal Finkel [mailto:[email protected]] > >> Sent: Wednesday, September 26, 2012 9:40 PM > >> To: Evan Cheng > >> Cc: Villmow, Micah; [email protected] LLVM; Nadav Rotem; cfe- > >> [email protected] 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 <[email protected]> wrote: > >> > >>> > >>> > >>> On Sep 26, 2012, at 11:07 AM, Hal Finkel <[email protected]> wrote: > >>> > >>>> On Tue, 25 Sep 2012 16:16:22 -0700 > >>>> Evan Cheng <[email protected]> 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" > >>>>> <[email protected]> wrote: > >>>>> > >>>>>> This time with the actual patch > >>>>>> > >>>>>> From: Villmow, Micah > >>>>>> Sent: Friday, September 21, 2012 4:08 PM > >>>>>> To: [email protected]; [email protected] > >>>>>> 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 > >>>>>> [email protected] > >>>>>> 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 > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > _______________________________________________ > llvm-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
