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

Thu Sep 27 15:40:15 PDT 2012

Lang,
I didn't know this function existed(getPointerSize). I could reuse that, with modification, but I think the problem here is one of how to efficiently access the data. The data is stored in the Module, but its accessed via TargetData. Having two different methods of parsing the target data I think is not good design, but that decision can wait until the BoF.

Micah

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Thursday, September 27, 2012 3:32 PM
To: Jim Grosbach
Cc: llvm-commits at cs.uiuc.edu LLVM; cfe-commits at cs.uiuc.edu cfe
Subject: Re: [llvm-commits] [cfe-commits] [Patch] Move TargetData from Target to Support/VMCore

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<mailto: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<mailto:Micah.Villmow at amd.com>> wrote:

>
>
>> -----Original Message-----
>> From: Hal Finkel [mailto:hfinkel at anl.gov<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<mailto:llvm-commits at cs.uiuc.edu> LLVM; Nadav Rotem; cfe-
>> commits at cs.uiuc.edu<mailto: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<mailto:evan.cheng at apple.com>> wrote:
>>
>>>
>>>
>>> On Sep 26, 2012, at 11:07 AM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote:
>>>
>>>> On Tue, 25 Sep 2012 16:16:22 -0700
>>>> Evan Cheng <evan.cheng at apple.com<mailto: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<mailto: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<mailto:llvm-commits at cs.uiuc.edu>; cfe-commits at cs.uiuc.edu<mailto: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<mailto: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<mailto: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<mailto: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/b536778b/attachment.html>