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