PTX backend, BSD license

Hi,

finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https://sourceforge.net/projects/llvmptxbackend/
It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010)

The backend now uses the address space attribute of LLVM for local, global, … and constant address space. However the clang frontend handles address space attributes incorrectly. Thus writing the input code in C++ is some times cumbersome. We need to fix clang in this regard.

Helge

Yes, we do! Please file bugs.

John.

"Helge Rhodin" <helge.rhodin@alice-dsl.net> writes:

Interesting!

                         -Dave

"Helge Rhodin" <helge.rhodin@alice-dsl.net> writes:

Hi,

finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https://
sourceforge.net/projects/llvmptxbackend/
It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010)

Is there work to upstream this? I've got a relatively unused NVIDIA
card at home. :slight_smile:

                                 -Dave

Hi,

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?

Thx,
Alex

P.S.: Sorry for double post, this belongs on llvmdev not cfe-dev

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,

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

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

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Alexander Herz
Sent: 19 October 2010 08:53
To: Jim Grosbach
Cc: llvmdev@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

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

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

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.