llvm dev - Oct 2010 - [LLVMdev] pass case sensitive information to a llvm target backend

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

Hi Alex,
>From your description it sounds like a simple string global using the
llvm::cl library would do the job just fine?

static cl::opt<std::string>
MyMetadataFilename("metadata-fname",
cl::desc("Description"),
cl::init(""));

Documentation can be found here: http://llvm.org/docs/CommandLine.html

You should have no problems - the CommandLine library is one of the best
designed interfaces I've yet to see.

Cheers,

James
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Alexander Herz
> Sent: 19 October 2010 08:53
> To: Jim Grosbach
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] pass case sensitive information to a llvm
> targetbackend
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- 
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

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.

-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
>

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>