[LLVMdev] pass case sensitive information to a llvm target backend

Devang Patel dpatel at apple.com
Wed Oct 20 08:56:11 PDT 2010


On Oct 19, 2010, at 10:04 AM, Jim Grosbach wrote:

> Hi Alex,
> 
> That sounds like the sort of information that should be extractable from the debug information metadata. Once you're in LLVM IR, things like class names and source types are not guaranteed to be preserved in a reverse-mappable sort of way (from IR names to source names) in the IR itself. The debug information, however, is intended to do exactly that.

Yes, you can do something like

!1 = metadata !"my_special_path1"
!2 = metadata !"my_special_pathABC"

!CIL_special_strings = !{!1, !2}

Now CIL_Special_strings will stay in llvm::Module till the end.
-
Devang

> -Jim
> 
> 
> On Oct 19, 2010, at 12:52 AM, Alexander Herz wrote:
> 
>> Hi,
>> 
>> we use the llvm to lower c++ code to c code which can be run through our abstract interpretation framework
>> (based on CIL). Along with the c code we emit some structured text files that contain the "lost" information
>> (class hierarchy, private/public attributes etc). In order to output this information in a sensible way we need to pass unix paths and some more case sensitive information (class names) to the backend (which is derived from the c backend).
>> 
>> Alex
>> 
>> On 10/18/2010 07:13 PM, Jim Grosbach wrote:
>>> On Oct 18, 2010, at 8:31 AM, Alexander Herz wrote:
>>> 
>>>> we're writing a new target backend (based on the c backend) for the
>>>> llvm. We need to pass case sensitive strings from the command line to
>>>> the backend (unix paths). Currently we're using the Subtarget features
>>>> string to relay the information.
>>>> It turns out that the llvm applies a to_lower to the this string, so
>>>> unix paths become basically useless.
>>>> Is there a better way to pass this information to the backend. If not,
>>>> what are the chances that a patch that disables the conversion to lower
>>>> case for this string is accepted?
>>>> 
>>> Hi Alex,
>>> 
>>> Whether there's a better way to pass the information you want to the backend will likely depend a bit more on the specifics of what you're trying to do. Can you elaborate a bit with a simple example, perhaps?
>>> 
>>> -Jim
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101020/53c18410/attachment.html>


More information about the llvm-dev mailing list