llvm dev - Feb 2013 - [LLVMdev] Problem with PTX assembly printing (NVPTX backend)

On Wed, Jan 30, 2013 at 12:02:47PM -0600, Matthew Curtis
wrote:
> Hello all,
> 
> In the process of porting the Polly plug-in to Windows we encountered a
couple
> of issues stemming from the use (within Polly) of global data from LLVM.
> 
> By far the most common occurrence of this is the definition by a class of a
> publicly accessible static ID, the address of which is used to uniquely
> identify the class. For example
> 
>     class AliasAnalysis {
> 
>     public:
>       static char ID; // Class identification, replacement for typeinfo
> 
>     };
> 
> 
> This turns out to be problematic on Windows for two reasons:
> 
> 1) We found that Visual Studio actually defines two copies of the ID, one
> within the clang executable and another within the Polly library. This
results
> in Polly being unable to identify LLVM passes. (This seems like a bug in
Visual
> Studio, but we could not find a resolution other than changing LLVM as
noted
> below).
> 2) We chose to use delay loading for symbols imported by Polly from clang.
This
> allows the Polly dll to be loaded into any executable that provides the
> required symbols. However delay loading precludes the importing of data[1].
> 
> We would like to resolve these issues by replacing public access of the ID
with
> a getter:
> 
>     class AliasAnalysis {
> 
>     private:
>       static char ID; // Class identification, replacement for typeinfo
> 
>     public:
>       static const void *getClassPassID();
>     };
  I think that would be O.K., but why getClassPassID return "const void
*" not just "char"?

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Hi all,

I'm trying to use the newly added (in LLVM 3.2) NVPTX backend for  
producing PTX (Parallel Thread eXecution) assembly from simple C  
programs.

While using llc with -march for mips and x86 works, -march=nvptx  
doesn't work. This seems reasonable since I can see that the  
libLLVMNVPTXAsmPrinter.a library is about 500 bytes (thus empty).  
However, the strange thing is that AsmPrinter code can be found in the  
NVPTX backend directory. I would expect that this code would be  
compiled to the corresponding assembly printing library.

Has anyone had similar problems with the NVPTX backend? Shouldn't this  
code be linked to the AsmPrinter library for NVPTX (already)?

BTW I've built LLVM with mingw (strange mixture of gcc-3.4.5 and  
g++-4.6.1). Native compilation, MIPS backend and other things that  
i've tested, all work properly.

Any help is appreciated.

Best regards,
Nikolaos Kavvadias

On Mon, Feb 04, 2013 at 08:06:46AM -0600, Matthew Curtis
wrote:
> On 1/31/2013 9:07 PM, 陳韋任 (Wei-Ren Chen) wrote:
> > On Wed, Jan 30, 2013 at 12:02:47PM -0600, Matthew Curtis wrote:
> >> Hello all,
> >>
> >> In the process of porting the Polly plug-in to Windows we
encountered a couple
> >> of issues stemming from the use (within Polly) of global data from
LLVM.
> >>
> >> By far the most common occurrence of this is the definition by a
class of a
> >> publicly accessible static ID, the address of which is used to
uniquely
> >> identify the class. For example
> >>
> >>      class AliasAnalysis {
> >>
> >>      public:
> >>        static char ID; // Class identification, replacement for
typeinfo
> >>
> >>      };
> >>
> >>
> >> This turns out to be problematic on Windows for two reasons:
> >>
> >> 1) We found that Visual Studio actually defines two copies of the
ID, one
> >> within the clang executable and another within the Polly library.
This results
> >> in Polly being unable to identify LLVM passes. (This seems like a
bug in Visual
> >> Studio, but we could not find a resolution other than changing
LLVM as noted
> >> below).
> >> 2) We chose to use delay loading for symbols imported by Polly
from clang. This
> >> allows the Polly dll to be loaded into any executable that
provides the
> >> required symbols. However delay loading precludes the importing of
data[1].
> >>
> >> We would like to resolve these issues by replacing public access
of the ID with
> >> a getter:
> >>
> >>      class AliasAnalysis {
> >>
> >>      private:
> >>        static char ID; // Class identification, replacement for
typeinfo
> >>
> >>      public:
> >>        static const void *getClassPassID();
> >>      };
> >    I think that would be O.K., but why getClassPassID return
"const void
> > *" not just "char"?
> 
> The class is actually identified by the address of 'ID'. The value
of
> 'ID' is irrelevant. So where it is currently used you will amost
always
> find '&ClassName::ID'.
  Understood. Maybe you can submit patch to llvm-commits to get more
attention, or ping someone who maintains this things.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj