[LLVMdev] printing constants

[anubham suresh]

Sir,
I am using the op_begin and op_end iterator for
iterating over the operands as mentioned below.

for (User::op_iterator
operand=j->op_begin(),operand_end=j->op_end();operand!=operand_end;++operand){
Value *v=operand->get();
const Type *t=v->getType();
cerr<<endl<<"    operand: "<<"[ "<<v->hasName()<<"
]"<<v->getName()<<" Type:"<<*t<< "  it has:  "<<
v->getNumUses()<<"--uses";
}

but by using this i  am able to print the variables
but not the constants .I am also able to print the
type of the constant but not the constant value.i am
getting a empty space for the constant.What should I
do for getting the constant printed out?

thanking you,

 yours sincerely,
suresh anubham 
tu darmstadt
germany

--- llvmdev-request at cs.uiuc.edu wrote:

> Send LLVMdev mailing list submissions to
> 	llvmdev at cs.uiuc.edu
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body
> 'help' to
> 	llvmdev-request at cs.uiuc.edu
> 
> You can reach the person managing the list at
> 	llvmdev-owner at cs.uiuc.edu
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of LLVMdev digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re: Re: New GCC4-based C/C++/ObjC
> front-end for LLVM
>       (Chris Lattner)
>    2. Re: llvm-java state (Alkis Evlogimenos)
>    3. Re: Re: Re: New GCC4-based C/C++/ObjC
> front-end for LLVM
>       (Chris Lattner)
>    4. printing constants (anubham suresh)
>    5. install dirs (Rogelio Serrano)
>    6. Re: install dirs (John Criswell)
>    7. Re: install dirs (Rogelio Serrano)
>    8. Re: printing constants (Chris Lattner)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 2 Mar 2006 15:23:26 -0600 (CST)
> From: Chris Lattner <sabre at nondot.org>
> Subject: Re: [LLVMdev] Re: Re: New GCC4-based
> C/C++/ObjC front-end for
> 	LLVM
> To: LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Message-ID:
> <Pine.LNX.4.61.0603021522360.2883 at nondot.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII;
> format=flowed
> 
> On Thu, 2 Mar 2006, Vladimir Prus wrote:
> >>> The instructions seem to have one path wrong. It
> says to get:
> >>
> >> I'll put together a tarball today.  That will be
> easier than dealing with
> >> a patch, and it will include a bunch of bugfixes
> since the previous email.
> > Further into process, I get this error:
> >  In file included from
> ../../llvm-new-frontend/gcc/llvm-backend.cpp:23:
> >  ../../llvm-new-frontend/gcc/llvm-internal.h:216:
> error: 'uint64_t' is used
> >  as a type, but is not defined as a type.
> >
> > Any ideas what could be wrong?
> 
> Sorry for the delay, please try this tarball:
> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz
> 
> In addition to fixing the specific error you list
> above, it also fixes 
> many other things.
> 
> Please let me know if you have any problems with it!
> 
> -Chris
> 
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 2 Mar 2006 15:07:36 -0800
> From: "Alkis Evlogimenos" <alkis at evlogimenos.com>
> Subject: Re: [LLVMdev] llvm-java state
> To: "LLVM Developers Mailing List"
> <llvmdev at cs.uiuc.edu>
> Message-ID:
> 
>
<82738b150603021507y151876c2nb76bf5e7d30c32fc at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 3/2/06, Kyle Wilkinson <kdwilkin at uiuc.edu> wrote:
> > Hi,
> >
> > This question is mostly addressed at Alkis, as I
> understand that he
> > last worked on llvm-java and I saw him reply to
> another thread
> > recently :-)
> >
> > When I try and run class2llvm I get a bus error
> because function_ in
> > VMMethod points to 0x8.
> 
> This can't be good :-)
> 
> > I think the problem lies in how I am using
> class2llvm.  When I read
> > through the Debug output, I see that class2llvm is
> trying to compile
> > all of the files distributed in the gnuclasspath,
> ~2500 classes. I
> > can't imagine a Hello World program needing all of
> those classes.
> 
> Well this is about right. And this stil ignores a
> lot of packages.
> With static compilation you need to compile the
> transitive closure of
> of all classes referenced in the program. A 'simple'
> Hello Worls is
> not that simple: it needs String, System, a bunch of
> the IO library,
> which in their own pull in stuff like Locale's,
> regular expressions, a
> bunch of java.util and so on. Note that you don't
> really need all of
> these for hello world but you can't really know for
> sure which method
> is called or not on each object.
> 
> My suggestion to solve this is to integrate
> class2llvm with the jit
> and compile a method at a time as they are called.
> This will shorted
> compilation by a lot as you will only get to compile
> functions that
> are actually called not all the functions that can
> potentially be
> called. My suggestion would be to first do that
> before you try to
> implement more features for the java front end.
> 
> > Here is how I am using class2llvm currently:
> >
> > // In test/Regression/ClassFile
> > jikes -cp /usr/local/share/classpath Hello.java
> > class2llvm -cp /usr/local/share/classpath:. Hello
> 
> This looks right to me. But if Hello.java contains a
> call to
> System.out.println() this will not work, because I/O
> doesn't work yet.
> Read on.
> 
> > Am I doing something wrong or using the tool
> improperly?  I thought I
> > would make sure I'm not doing something really
> stupid before I try
> > and debug this error.
> >
> > Do you happen to remember the state of the source
> code before you
> > left? After I get past this hurdle, I am planning
> on implementing
> > synchronization and Prof. Adve thought that
> synchronization and
> > exceptions were about the only things missing, but
> any advice or
> > thoughts on that would be welcome.
> 
> Before I left I was at the point where I got most of
> the Java->Native
> part of JNI working and made a lot of progress in
> the Native->Java
> interface. This was an effort to get I/O working
> (finally) because I/O
> actually uses native libraries for its
> implementation. Once you get to
> the point where native code can call Java code
> without bugs you should
> in theory be done and ready to run your Hello World
> using
> System.out.println(...).
> 
> If you take a look at the tests in the llvm-java
> directory, you can
> see that I/O is done through a native library (as I
> said Java->Native
> JNI works).
> 
> Also take a look at the way tests are compiled.
> Since the compiler
> can't compile everything there are a lot of packages
> that are excluded
> from compilation. This leaves a lot of referenced
> functions 
=== message truncated ===


Anubham Suresh 
Measurement and Instrumentation
Electrical Department
IIT Roorkee
Current location:Darmstadt, Germany
mobile: +49-1762-3924878


		
__________________________________________________________ 
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com