From sabre at nondot.org  Fri Aug  1 17:29:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Fri Aug  1 17:29:01 2003
Subject: [LLVMdev] Changes to the DEBUG macro.
Message-ID: <Pine.LNX.4.44.0308011733380.12547-100000@nondot.org>

This is an important change for people using the DEBUG macro (which should
be all of you :).  The critical piece is that you now need to #include
"Support/Debug.h" to get access to DEBUG, not "Support/Statistic.h".

In addition to this change, you can now make the DEBUG output much more
fine-grained than before.  For details, consult the programmer's guide:
http://llvm.cs.uiuc.edu/docs/ProgrammersManual.html#DEBUG_TYPE

This feature was requested by Misha, because whenever he enabled -debug in
the code generator, he got all kinds of debug output from all of the
different components of it.  Now he can classify debug output into
different types, and only turn on subsets of the information.

Enjoy,

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From bdraco at gte.net  Mon Aug  4 01:29:02 2003
From: bdraco at gte.net (bdraco at gte.net)
Date: Mon Aug  4 01:29:02 2003
Subject: [LLVMdev] did you see this
Message-ID: <200308040628.h746S5kX012369@dcs-server2.cs.uiuc.edu>

An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030804/9cc13704/attachment.html>

From whug82qvu at bigfoot.com  Fri Aug  8 08:32:01 2003
From: whug82qvu at bigfoot.com (Booker Dean)
Date: Fri Aug  8 08:32:01 2003
Subject: [LLVMdev] how to have POWER erections   yvddahws shx
Message-ID: <2d8-a-n-sm$h46@l7yd0.7.2.6dw>

An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030808/fb94a7bf/attachment.html>

From robert at mykland.com  Fri Aug  8 12:17:02 2003
From: robert at mykland.com (Robert Mykland)
Date: Fri Aug  8 12:17:02 2003
Subject: [LLVMdev] Spammers
In-Reply-To: <20030808170005.24276.21171.Mailman@dcs-server2.cs.uiuc.edu
 >
Message-ID: <5.1.0.14.0.20030808102100.00a85ec0@mail.mykland.com>

Clearly spammers have entered our midst.  Having this list be moderated 
would be a good thing I think.

-- Robert.

At 12:00 PM 8/8/03 -0500, you wrote:
>Send LLVMdev mailing list submissions to
>         llvmdev at cs.uiuc.edu
>
>To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.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-admin 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. how to have POWER erections   yvddahws shx (Booker Dean)
>
>--__--__--
>
>Message: 1
>From: "Booker Dean" <whug82qvu at bigfoot.com>
>Reply-To: "Booker Dean" <whug82qvu at bigfoot.com>
>To: llvmdev at cs.uiuc.edu
>Date: Sat, 09 Aug 03 04:26:22 GMT
>Subject: [LLVMdev] how to have POWER erections   yvddahws shx
>
>
>--4_5.F0_6C_AC__4A482B1_A
>Content-Type: text/html;
>Content-Transfer-Encoding: quoted-printable
>
><div align=3D"center"><font face=3D"Helvetica, Arial, sans-serif" ><font s=
>ize=3D"+3" >"Si<L>ze
>does ma<N>tter!"<P>
><b>NATURAL PE<M>N<N>IS ENL<H>ARGE<N>ME<M>NT!</b></font><P><font color=3D"r=
>ed" size=3D"+1"><b>GAIN 3 Inches to your Penis, with VPRX
>penis pills!</b></font><P>
><b>CURE IMP<F>OTENCE! GAIN ST<K>AMIN<G>A! HARDEN EREC<K>TIONS!<br>
>100% GUAR<K>ANTEED RE<K>SULTS!</b><br>
><br>
>SPEC<K>IAL DEAL TODAY!! ORD<K>ER 3 AND GET 3 FREE!!!<br>
><BR><font size=3D"+3" >
><a href=3D"http://www.hijkl.com/click.php?terra">EN<K>TER HE<K>RE</a></fon=
>t><BR><BR><BR><BR><BR></div></font>
><a href=3Dhttp://www.hijkl.com/remove.html>Rem<N>ove</a>qtcflzlk  ne  d
>tp g
>b al xv uno u jq
>mg ozb
>u w
>   tvbxbbf stg
>ohuzk
>
>--4_5.F0_6C_AC__4A482B1_A--
>
>
>
>--__--__--
>
>_______________________________________________
>LLVMdev mailing list
>LLVMdev at cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>End of LLVMdev Digest

Robert Mykland     Voice: (831) 462-6725



From sabre at nondot.org  Fri Aug  8 13:58:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Fri Aug  8 13:58:01 2003
Subject: [LLVMdev] Spammers
In-Reply-To: <5.1.0.14.0.20030808102100.00a85ec0@mail.mykland.com>
Message-ID: <Pine.LNX.4.44.0308081404150.2878-100000@nondot.org>

On Fri, 8 Aug 2003, Robert Mykland wrote:

> Clearly spammers have entered our midst.  Having this list be moderated
> would be a good thing I think.

Hrm, I think you're right, though I would be really impressed if LLVM got
a POWER erection, or lost money on a home loan.  :)

The list is now moderated.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From rujoshi at uiuc.edu  Wed Aug 13 15:32:01 2003
From: rujoshi at uiuc.edu (Rahul Joshi)
Date: Wed Aug 13 15:32:01 2003
Subject: [LLVMdev] Running a pass
Message-ID: <3a031dcd.b2e60aba.818e800@express.cites.uiuc.edu>

Hi,

I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct:

TS_ASSERT(!verifyFunction(*function));

// find the dominance frontier of the CFG
DominanceFrontier DF;
DF.runOnFunction(*function);

// try to promote stack allocated variables
PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data);

function->print(std::cout);
TS_ASSERT(!verifyFunction(*function));

Is this supposed to work? Or what is the preferred way passes
are to be run on functions? With the above code, my program
crashes even before main(), when doing some static 
initialization in Type.cpp.

Thanks,
Rahul


From sabre at nondot.org  Wed Aug 13 15:39:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Wed Aug 13 15:39:01 2003
Subject: [LLVMdev] Running a pass
In-Reply-To: <3a031dcd.b2e60aba.818e800@express.cites.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0308131543450.10244-100000@nondot.org>

On Wed, 13 Aug 2003, Rahul Joshi wrote:
> I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct:
> TS_ASSERT(!verifyFunction(*function));
> // find the dominance frontier of the CFG
> DominanceFrontier DF;
> DF.runOnFunction(*function);
> // try to promote stack allocated variables
> PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data);

This won't work.  Passes are supposed to be run by the PassManager (see
http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html), which figures out
what the dependencies of the passes are.

In this case, DominanceFrontier depends on DominatorTree (which depends on
DominatorSet), all of which the PassManager automatically figures out and
runs.

If you want to run the mem2reg pass, this means you need to do something
along these lines:

PassManager PM;
PM.add(new PromoteMem2Reg());
PM.run(M);  // M is your module.

Alternatively, if you just want to run it a function-at-a-time, you can
use the new FunctionPassManager which Brian just checked in.

> Is this supposed to work? Or what is the preferred way passes
> are to be run on functions? With the above code, my program
> crashes even before main(), when doing some static
> initialization in Type.cpp.

I'm not sure what is causing this problem, if main is not even executing
yet, then it shouldn't matter what your main does.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From rujoshi at uiuc.edu  Wed Aug 13 16:57:01 2003
From: rujoshi at uiuc.edu (Rahul Joshi)
Date: Wed Aug 13 16:57:01 2003
Subject: [LLVMdev] Running a pass
Message-ID: <77633193.b2ee2aae.818ef00@express.cites.uiuc.edu>

Hi,

I assume that since each pass is in its own anonymous
namespace, we cannot directly create a new pass object;
looking at the code for 'opt' utility, it seems we need a
PassInfo object, using which we create a new pass object.
I tried the following code (which I wrote after looking at
the code for bugpoint), but the list of passes seems to be
empty:

// Create a list of all the registered passses
static cl::list<const PassInfo*, bool, PassNameParser>
PassList(cl::desc("Passes available:"), cl::ZeroOrMore);


mem2reg_pass = NULL;
for(It i = PassList.begin(); i != PassList.end(); i++) {
   std::cout << (*i)->getPassName() << endl;
   if(string("mem2reg") == (*i)->getPassName()) {
      mem2reg_pass = *i;
      break;
    }
}
assert(mem2reg_pass);
assert(mem2reg_pass->getNormalCtor());

The first assert always fails, and none of the pass names
appear on the output. So how can I obtain a pointer to the
pass I want to run, so that I can use the pass manager?


>I'm not sure what is causing this problem, if main is not even executing
>yet, then it shouldn't matter what your main does.  :)

This is apparently caused by the linking the 'ipo' library.
I removed that from my Makefile, and it does not happen any
more.

Thanks,
Rahul


From sabre at nondot.org  Wed Aug 13 17:05:03 2003
From: sabre at nondot.org (Chris Lattner)
Date: Wed Aug 13 17:05:03 2003
Subject: [LLVMdev] Running a pass
In-Reply-To: <77633193.b2ee2aae.818ef00@express.cites.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0308131712230.11015-100000@nondot.org>

> I assume that since each pass is in its own anonymous
> namespace, we cannot directly create a new pass object;
> looking at the code for 'opt' utility, it seems we need a
> PassInfo object, using which we create a new pass object.
> I tried the following code (which I wrote after looking at
> the code for bugpoint), but the list of passes seems to be
> empty:

Being in an anonymous namespace just means you cannot invoke the methods
of the pass directly.  Given a pointer to an object of that pass, however,
you can invoke virtual methods and otherwise use the pass.

To get a pointer to an instance of the mem2reg pass, just call
createPromoteMemoryToRegister(), declared in
include/llvm/Transforms/Scalar.h

> >I'm not sure what is causing this problem, if main is not even executing
> >yet, then it shouldn't matter what your main does.  :)
>
> This is apparently caused by the linking the 'ipo' library.
> I removed that from my Makefile, and it does not happen any
> more.

I'm not sure what could possibly cause this.  If you send me details
(off-list) I would be happy to look into it.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From sabre at nondot.org  Fri Aug 15 14:06:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Fri Aug 15 14:06:01 2003
Subject: [LLVMdev] LLVM Status Update
Message-ID: <Pine.LNX.4.44.0308151339420.3273-100000@nondot.org>

Ok, the last status update (http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-June/000416.html)
was over 7 weeks ago, sorry about that.  We've been really busy squishing
bugs, improving stability, and otherwise improving the system for the
release.  Here are some of the major accomplishments in LLVM since the
last update...

1. We finally have the go-ahead from the university to release LLVM under
   the Illinois Open Source License (http://www.opensource.org/licenses/UoI-NCSA.php),
   which is an OSI approved license similar in spirit to the BSD license.
   This is good for us, because now the barriers to the release are purely
   technical, not political.  :) :)

2. John has LLVM completely autoconfiscated, which makes the system
   dramatically easier to set up and use!  He and Dinakar also wrapped up
   the "Projects" system, which allows loosely connected LLVM projects to
   be built outside of the LLVM tree, while making use of all of the
   makefile machinery we already have.

3. Brian finished up the static compiler (LLC) backend for the X86, and it
   works great.  Misha has the Sparc JIT working, which means that both
   the Sparc and X86 backends work in both JIT and Static configurations
   now!  Misha also added nightly tester support for the Sparc, so we can
   track its progress as well.

4. Vikram found and fixed a bunch of bugs in the Sparc backend, which
   makes it work a lot better on SPECINT2000!

5. Brian wrote a new Name Mangler interface which allows all of the
   back-ends to share a single common implementation, eliminating a bunch
   of redundant code!

6. Chris checked in a couple of improvements to the target-independent
   portions of the JIT, which sped it up by about 25% overall.

7. Large chunks of the X86 backend are now automatically generated from a
   TableGen description file,

8. Misha added a mode to bugpoint to automatically debug buggy code
   generators.  It supports both the static and JIT compilers.

9. The Data Structure Analysis implementation is now greatly improved and
   more efficient than before, and now has a "GraphChecker" pass which
   allows us to write nice regression tests for it.

10. Improvements in the C frontend and in the Sparc backend now make LLVM
    work a lot better with standard configure scripts (./configure CC=llvmgcc)

11. Minor improvements:
    - LOTS of minor bugs fixed
    - The C Backend now supports the invoke instruction
    - Misha wrote Emacs and VIM syntax highlighting modes for TableGen files
    - Substantial improvements to the instcombine and reassociation passes
    - New DEBUG_TYPE macro: http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-August/000439.html
    - The -trace[m] runtime has been improved

12. Lots of house cleaning and restructuring are happening to the LLVM
    sourcebase and build system as we prepare for the big release.  LLVM
    now compiles with GCC 3.3.

Although a lot of progress is being made, it looks like we may have to
slip the 1.0 release until the middle or end of september (~1 month), to
get the infrastructure for bug-tracking and regression testing up to
speed, as well as perform more testing.  We want this to be the most solid
1.0 release possible.  :)

That said, if you don't already have a copy of LLVM, and would like one,
we can probably provide you with a prerelease.  Just get in touch with
Vikram and myself off list (we don't want the slip to stop anyone from
using LLVM, we just want the final official release to be as useful as
possible).

If you have any questions or comments, feel free to email the llvmdev list
or me directly depending on what it is.  Have fun LLVMing!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/










From sabre at nondot.org  Mon Aug 18 12:32:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Mon Aug 18 12:32:01 2003
Subject: [LLVMdev] Cleaning out .d files
Message-ID: <Pine.LNX.4.44.0308181239000.12318-100000@nondot.org>

I just wanted to mention that there is a new global makefile target "make
cleandeps", which recursively walks through the source tree, deleting .d
files, without removing anything else.

This is useful when you update from CVS, and find out that there has been
a header file removed.  Before you'd have to go in and remove the
outdated .d manually, now you can just run 'make cleandeps'.

Obviously it would be nice if this probably didn't exist at all, but I
don't know of a good solution to this problem...

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From ccarter at cs.uiuc.edu  Wed Aug 20 22:32:00 2003
From: ccarter at cs.uiuc.edu (Casey Carter)
Date: Wed Aug 20 22:32:00 2003
Subject: [LLVMdev] Cleaning out .d files
In-Reply-To: <Pine.LNX.4.44.0308181239000.12318-100000@nondot.org>
References: <Pine.LNX.4.44.0308181239000.12318-100000@nondot.org>
Message-ID: <3F441FC6.6000006@cs.uiuc.edu>

Chris Lattner wrote:

>I just wanted to mention that there is a new global makefile target "make
>cleandeps", which recursively walks through the source tree, deleting .d
>files, without removing anything else.
>
>This is useful when you update from CVS, and find out that there has been
>a header file removed.  Before you'd have to go in and remove the
>outdated .d manually, now you can just run 'make cleandeps'.
>
>Obviously it would be nice if this probably didn't exist at all, but I
>don't know of a good solution to this problem...
>
>-Chris
>
>  
>
One slightly hackish way to deal with this problem is to have an 
implicit "empty" rule for .h files:

%.h: ;

make tries to use this rule to "generate" .h files that don't exist. 
 Nothing is actually done (the ";" is an empty command list) but make 
decides that it can/must rebuild stuff that depends on the .h file.  So 
the build can then continue to the point that the .d file gets 
regenerated by compilation.

Option 2 is to post-process the .d files and add a line for each header 
file with no dependencies and no commands:

foo.c: bar.h baz.h
bar.h:
baz.h:

which achieves the same end but without side effects.

-- 
Casey Carter
Casey at Carter.net
ccarter at cs.uiuc.edu
AIM: cartec69




From gaeke at uiuc.edu  Thu Aug 21 15:14:01 2003
From: gaeke at uiuc.edu (Brian R. Gaeke)
Date: Thu Aug 21 15:14:01 2003
Subject: [LLVMdev] reoptimizer note
Message-ID: <20030821200926.GA23040@niobe.cs.uiuc.edu>

Hello,

In preparation for the LLVM public release, I've moved the reoptimizer
out of the main cvs module "llvm" and into the cvs module "reopt". You
can go ahead and delete the lib/Reoptimizer directory from your tree,
about which cvs will undoubtedly be complaining to you.

If you want to build the reoptimizer, cd into your SPARC tree's
"projects" subdirectory and run "cvs co reopt". Then you will need to
run "./configure", giving the "--with-llvmsrc" and "--with-llvmobj"
options to tell it where your source and object directories are.

If you want to run the reoptimizer on a program, go into reopt/test and
run "gmake SUBDIR=d" where d is the subdirectory of llvm/test/Programs
that contains the program you're interested in. For example, "gmake
SUBDIR=MultiSource/Burg" should run the reoptimizer on burg.

(The reoptimizer's include files still live in the "llvm" module at
llvm/include/llvm/Reoptimizer; they will be moving into "reopt" soon.)

-Brian

-- 
gaeke at uiuc.edu


From sabre at nondot.org  Thu Aug 21 15:41:03 2003
From: sabre at nondot.org (Chris Lattner)
Date: Thu Aug 21 15:41:03 2003
Subject: [LLVMdev] Cleaning out .d files [IMPORTANT CHANGE, read below]
In-Reply-To: <3F441FC6.6000006@cs.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0308211544470.28102-100000@nondot.org>

> >Obviously it would be nice if this probably didn't exist at all, but I
> >don't know of a good solution to this problem...

> Option 2 is to post-process the .d files and add a line for each header
> file with no dependencies and no commands:
>
> foo.c: bar.h baz.h
> bar.h:
> baz.h:
> which achieves the same end but without side effects.

So right you are.  :)  I've just checked this fix into the tree:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20030818/006326.html

This means that everyone should do something like this next time you want
to update your tree:

cd ~/llvm            # from the top...
make cleandeps       # remove all .d files
utils/cvsupdate.sh   # Get new Makefile.common
make                 # rebuild all "new and improved" .d files

The new .d files won't cause errors when headers get moved, so I removed
the 'cleandeps' target from CVS, it should be unnecessary now.  :) :)

If you update your tree before running cleandeps, you can manually remove
all .d files as before with a 'find' command.

Thanks Casey!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From robert at mykland.com  Tue Aug 26 15:44:01 2003
From: robert at mykland.com (Robert Mykland)
Date: Tue Aug 26 15:44:01 2003
Subject: [LLVMdev] Seemingly ambiguous parameter lists
Message-ID: <5.2.1.1.0.20030826102557.00aaf3a8@mail.mykland.com>

LLVMers,

And while we're on the subject to the type definitions table, what's the 
difference between

0e 07 01 00
function returning Int ( Void )?  Function returning Int ( ... )?

and

0e 07 00
Function returning Int ()

I'm guessing the former really is a function returning Int ( ... ), but how 
is the callee supposed to decode the parameter list?  I'm an old callee and 
I don't know this new trick.  :-)

-- Robert.


Robert Mykland     Voice: (831) 462-6725 



From robert at mykland.com  Tue Aug 26 15:44:37 2003
From: robert at mykland.com (Robert Mykland)
Date: Tue Aug 26 15:44:37 2003
Subject: [LLVMdev] Question: Bytecode Representation of Type Definitions Table
Message-ID: <5.2.1.1.0.20030826085858.00aaf190@mail.mykland.com>

Distinguished LLVM Creators,

I've been looking through the bytecode representation of the type 
definition table and had a few questions about it.  There's an enum in 
Types.h that defines all bytecodes that represent the primitive types and a 
few other necessary things:

  0 = 0x00 = Void
  1 = 0x01 = Bool
  2 = 0x02 = UByte
  3 = 0x03 = SByte
  4 = 0x04 = UShort (16 bits)
  5 = 0x05 = Short (16 bits)
  6 = 0x06 = UInt (32 bits)
  7 = 0x07 = Int (32 bits)
  8 = 0x08 = ULong (64 bits)
  9 = 0x09 = Long (64 bits)
10 = 0x0a = Float (32 bits)
11 = 0x0b = Double (64 bits)
12 = 0x0c = Type definition
13 = 0x0d = Label
14 = 0x0e = Function
15 = 0x0f = Struct
16 = 0x10 = Array
17 = 0x11 = Pointer
18 = 0x12 = Opaque

As far as I can figure, the type definition table itself starts back at 
0x0e and I'm thinking that's because the label is the last thing that 
wouldn't have to be only part of a derived type.  But it still seems to 
make some of the low entries in the table ambiguous (at least to me!).  I 
compiled a nice little hello world program into LLVM and then into 
bytecodes (see complete results attached).  Here is the start of the type 
definition table:

Entry 0x0e: Pointer to type 0x0f
0000001a  11 0f

Entry 0x0f: Array of SByte [14] (presumably for "Hello World!\n" constant)
0000001c  10 03 0e

Entry 0x10: Pointer to type 0x12
0000001f  11  |....n...n.......|
00000020  12

Entry 0x11: Pointer to SByte
00000021  11 03

Entry 0x12: Function returning Pointer ( UInt )
00000023  0e 11 01 06

Okay, so looking at entry 0x10: is it a pointer to Opaque or a pointer to a 
function returning Pointer ( UInt )?  I'm guessing the latter.  Similarly, 
entry 0x0e could be a pointer to Struct or a pointer to Array of SByte 
[14].  Again I'm guessing the latter.  I'm worried this low table stuff 
isn't unambiguous in all cases, but then again I'm a nervous guy.  If you 
could set my mind at ease with regard to the lack of ambiguity that would 
be great.

And what's with this Opaque type anyway?  It's in the enum but I haven't 
found an instance of its use, unless of course it's used in entry 
0x10.  The whole missing Opaque thing makes me nervous too.  It seems like 
it was just put there to be unclear.  :-)  But seriously, is it used for 
anything now?  Will it start to get used sometime?

Regards,

-- Robert.


Robert Mykland     Voice: (831) 462-6725 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.hexdump
Type: application/octet-stream
Size: 26620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030826/977bdee1/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hello.c
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030826/977bdee1/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.s
Type: application/octet-stream
Size: 10437 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030826/977bdee1/attachment-0001.obj>

From khamenya at mail.ru  Tue Aug 26 15:44:43 2003
From: khamenya at mail.ru (=?koi8-r?Q?=22=F7=C1=CC=C5=D2=C9=CA=20=E8=C1=CD=C5=CE=D1=22=20?=)
Date: Tue Aug 26 15:44:43 2003
Subject: [LLVMdev] repeated recursion with =?koi8-r?Q?=22?=frozen=?koi8-r?Q?=22=20?=arguments
Message-ID: <E19rfCT-000NcU-00.khamenya-mail-ru@f7.mail.ru>

Hi llvm-devels, 

there is a very simple using case concerning LLVM and I am wondering whether it might be optimized at LLVM layer:

//-----------
int rec_func(int x, int y) {
  if(y<0) return x;
  return y + rec_func(x, y-1); // should we really push x?
}
void main() {
  rec_func(1, 1000);
  rec_func(2, 2000);
}
//-----------

Guys, don't focus on a stupid mathematics beyond this function :)
Please focus your attention at the fact, that argument `x'
is once supplied at the top level calls in `main' and 
never changed anymore from within `rec_func' function.

This example is just quite close to a "lexical closures" specifics.

The similar things we have when we pass `this' pointer 
to non-static member functions in C++ (why should we 
pass `this' pointer always if it was not changed?). 

However, I guess in classical code generation approaches 
argument `x' (like `this' pointer) is always pushed into 
a stack with _every_ call.

But, it is possible to generate individual code implementations 
for every top-level call of `rec_func' to avoid big number of
extra `push'.

In terms of C++: there should be a possibility to regenerate
non-static member functions for a given instantiated object 
of the classes where performance is critical, e.g. for classes
like valarray.

So, my questions are:

Q1. should/might the optimization like this be resolved at LLVM layer?

if "yes" then 

Q2. is LLVM capable of doing things like that today?

Thanks.
--
Valery


From sabre at nondot.org  Tue Aug 26 15:52:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Tue Aug 26 15:52:01 2003
Subject: [LLVMdev] repeated recursion with =?koi8-r?Q?=22?=frozen=?koi8-r?Q?=22=20?=arguments
In-Reply-To: <E19rfCT-000NcU-00.khamenya-mail-ru@f7.mail.ru>
Message-ID: <Pine.LNX.4.44.0308261557310.13871-100000@nondot.org>

> there is a very simple using case concerning LLVM and I am wondering
> whether it might be optimized at LLVM layer:
>
> //-----------
> int rec_func(int x, int y) {
>   if(y<0) return x;
>   return y + rec_func(x, y-1); // should we really push x?
> }

Probably not, at least not in the near future.  At some point I have had
thoughts about implementing a tail recursion pass, but without prior
transformation, this function would not be a candidate.

> Please focus your attention at the fact, that argument `x'
> is once supplied at the top level calls in `main' and
> never changed anymore from within `rec_func' function.
> This example is just quite close to a "lexical closures" specifics.

The problem with "lexical closures", at least in this instance, is that
you have to pass a pointer to the closure around: if you only have one
parameter which can use it, you aren't saving anything.

> The similar things we have when we pass `this' pointer
> to non-static member functions in C++ (why should we
> pass `this' pointer always if it was not changed?).

In C++, the 'this' object pointer can actually be thought of as a closure
in some sense already...

> However, I guess in classical code generation approaches
> argument `x' (like `this' pointer) is always pushed into
> a stack with _every_ call.

Absolutely.

> But, it is possible to generate individual code implementations
> for every top-level call of `rec_func' to avoid big number of
> extra `push'.

In terms of LLVM you could certainly do this.  For example you could
translate it to use an explicit stack:

int rec_func(int x, int y) {
  if(y<0) return x;
  return y + rec_func(x, y-1); // should we really push x?
}

Or you could just perform an aggressive dead code elimination pass which
would realize that this function returns the same value for X no matter
what the value of Y is.  There are other transformations that you can do
to work on this kind of thing, the functional language community has a lot
of ways to deal with this.

> In terms of C++: there should be a possibility to regenerate
> non-static member functions for a given instantiated object
> of the classes where performance is critical, e.g. for classes
> like valarray.

Sure, but you still need the 'this' pointer, to know WHICH valarray you
are talking about... ?

> So, my questions are:
> Q1. should/might the optimization like this be resolved at LLVM layer?

Yes, LLVM is designed for spiffy optimizations like this.  :)

> if "yes" then
> Q2. is LLVM capable of doing things like that today?

Nope, not yet.  Contributions are always appreciated though.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From sabre at nondot.org  Tue Aug 26 16:04:02 2003
From: sabre at nondot.org (Chris Lattner)
Date: Tue Aug 26 16:04:02 2003
Subject: [LLVMdev] Question: Bytecode Representation of Type Definitions
 Table
In-Reply-To: <5.2.1.1.0.20030826085858.00aaf190@mail.mykland.com>
Message-ID: <Pine.LNX.4.44.0308261606110.13991-100000@nondot.org>

> As far as I can figure, the type definition table itself starts back at
> 0x0e and I'm thinking that's because the label is the last thing that
> wouldn't have to be only part of a derived type.

Exactly right.  The types starting with the function type never appear
explictly in the table/they don't occupy a "slot".  Derived types are only
used to build concrete types from other things.  :)

> But it still seems to make some of the low entries in the table
> ambiguous (at least to me!).  I compiled a nice little hello world
> program into LLVM and then into bytecodes (see complete results
> attached).  Here is the start of the type definition table:

Ok.

> Entry 0x0e: Pointer to type 0x0f
> 0000001a  11 0f

Yes, since type 0x0F is '[14 x sbyte]', this is '[14 x sbyte]*'.  Forward
references are required for things like recursive types.

> Entry 0x0f: Array of SByte [14] (presumably for "Hello World!\n" constant)
> 0000001c  10 03 0e

Yup.

> Entry 0x10: Pointer to type 0x12
> 0000001f  11  |....n...n.......|
> 00000020  12

Yup: 'sbyte* (uint)*'

> Entry 0x11: Pointer to SByte
> 00000021  11 03

'sbyte*'

> Entry 0x12: Function returning Pointer ( UInt )
> 00000023  0e 11 01 06

'sbyte* (uint)

> Okay, so looking at entry 0x10: is it a pointer to Opaque or a pointer to a
> function returning Pointer ( UInt )?  I'm guessing the latter.  Similarly,
> entry 0x0e could be a pointer to Struct or a pointer to Array of SByte
> [14].  Again I'm guessing the latter.

You're right.  The parsing algorithm goes like this:

Read a byte.  This defines the 'typeid' to use for the type.  This is
ne of the values from the Type.h file, including things like
structure, pointer, opaque, function, ... as well as the primitive
types.

If it's a derived type, extra information is read indicating what type of
parameters there are for functions, which the pointee of a pointer is,
etc.  These type id's are type #'s, not primitive ID numbers.  You cannot
refer to a "generic" structure or function or anything like that.  Forward
references are allowed.

> I'm worried this low table stuff isn't unambiguous in all cases, but
> then again I'm a nervous guy.  If you could set my mind at ease with
> regard to the lack of ambiguity that would be great.

It seems to work so far.  :)  It should be ambiguous, we haven't had any
problems.

> And what's with this Opaque type anyway?  It's in the enum but I haven't
> found an instance of its use, unless of course it's used in entry
> 0x10.  The whole missing Opaque thing makes me nervous too.  It seems like
> it was just put there to be unclear.  :-)

Opaque type is for a type that does not have a definition yet.  In C, for
example, if you say 'struct foo;' and never provide the body, you get an
llvm type like:

%struct.foo = opaque;

Allowing you to build definitions like '%struct.foo*', etc.  Later, when
the type is resolved in the linking phase, all of these types are updated
to have their "true" values.

> But seriously, is it used for anything now?  Will it start to get used
> sometime?

It is used extensively for a lot of things, including the "forward
referencing" of types in the bytecode and asm files...

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From sabre at nondot.org  Tue Aug 26 16:07:08 2003
From: sabre at nondot.org (Chris Lattner)
Date: Tue Aug 26 16:07:08 2003
Subject: [LLVMdev] Seemingly ambiguous parameter lists
In-Reply-To: <5.2.1.1.0.20030826102557.00aaf3a8@mail.mykland.com>
Message-ID: <Pine.LNX.4.44.0308261615160.13991-100000@nondot.org>

On Tue, 26 Aug 2003, Robert Mykland wrote:
> And while we're on the subject to the type definitions table, what's the
> difference between
>
> 0e 07 01 00
> function returning Int ( Void )?  Function returning Int ( ... )?

Void is not a legal argument.  The bytecode file uses the void marker as
a way to store the ... for a varargs function.  IE, the declaration:

void foo(void);

in C, becomes the LLVM type 'void ()*' %foo.  The C declaration:

void foo(...);

becomes the LLVM type 'void (...)*' %foo, which is stored in the bytecode
file (to be compact) as 'void (void)*'.

> 0e 07 00
> Function returning Int ()

That is just 'int ()', function returning int, with no arguments.

> I'm guessing the former really is a function returning Int ( ... ), but how
> is the callee supposed to decode the parameter list?  I'm an old callee and
> I don't know this new trick.  :-)

Void is not a legal argument type, it is just used as a marker in the
bytecode files.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From sabre at nondot.org  Tue Aug 26 16:31:00 2003
From: sabre at nondot.org (Chris Lattner)
Date: Tue Aug 26 16:31:00 2003
Subject: [LLVMdev] repeated recursion with "frozen" arguments
In-Reply-To: <2218043294.20030826232459@mail.ru>
Message-ID: <Pine.LNX.4.44.0308261640200.14225-100000@nondot.org>

> CL> Probably not, at least not in the near future.  At some point I have had
> CL> thoughts about implementing a tail recursion pass, but without prior
> CL> transformation, this function would not be a candidate.
>
> wait... if you break this C-example at the place as you did then it is
> absolutely not what I have meant. Indeed, sense of my example comes
> iff the top-level call is given, i.e. it might be optimized in
> the context of concrete external call.

Yup, I think I completely missed your point.  :)

> generally you are right. But only generally :)
> In particular, my example showed a feature of typical lexical closure.

Can you explain more about what you mean.  I don't think I understand.

> CL> In terms of LLVM you could certainly do this.  For example you could
> CL> translate it to use an explicit stack:

> then I have to dig LLVM docs about explicit stack :)

I just mean you have an explicit stack data structure to store just the
elements the recursive call needs.

> CL> Sure, but you still need the 'this' pointer, to know WHICH valarray you
> CL> are talking about... ?
>
> sure. But what if this `this' was set once for 1mio calls?
> Today I have a lot heavy math function working with two spectra and
> every time I have to think twice before making another member function
> which is invoked in deeper stack frames.

varray's do not have any recursive function calls, and the methods tend to
be simple.  For that reason, they are typically all inlined, eliminating
the parameter passing completely...

> In other words, just imagine the situation, when for a given object
> really a lot of *its* members function are called without changing
> `this'. Today compilers can't eliminate this _extra_ `this'. And real
> C++ code has tendency to be slower.

I really am not sure I understand what transformation you are proposing.
Can you elaborate more?  :)

Thanks,

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From khamenya at mail.ru  Tue Aug 26 16:32:02 2003
From: khamenya at mail.ru (Valery A.Khamenya)
Date: Tue Aug 26 16:32:02 2003
Subject: [LLVMdev] repeated recursion with "frozen" arguments
In-Reply-To: <Pine.LNX.4.44.0308261557310.13871-100000@nondot.org>
References: <Pine.LNX.4.44.0308261557310.13871-100000@nondot.org>
Message-ID: <2218043294.20030826232459@mail.ru>

Hello Chris,

Tuesday, August 26, 2003, 11:02:45 PM, you wrote:

>> there is a very simple using case concerning LLVM and I am wondering
>> whether it might be optimized at LLVM layer:
>>
>> //-----------
>> int rec_func(int x, int y) {
>>   if(y<0) return x;
>>   return y + rec_func(x, y-1); // should we really push x?
>> }

CL> Probably not, at least not in the near future.  At some point I have had
CL> thoughts about implementing a tail recursion pass, but without prior
CL> transformation, this function would not be a candidate.

wait... if you break this C-example at the place as you did then it is
absolutely not what I have meant. Indeed, sense of my example comes
iff the top-level call is given, i.e. it might be optimized in
the context of concrete external call.

CL> The problem with "lexical closures", at least in this instance, is
CL> that you have to pass a pointer to the closure around: if you only
CL> have one parameter which can use it, you aren't saving anything.

generally you are right. But only generally :)
In particular, my example showed a feature of typical lexical closure.

>> The similar things we have when we pass `this' pointer
>> to non-static member functions in C++ (why should we
>> pass `this' pointer always if it was not changed?).

CL> In C++, the 'this' object pointer can actually be thought of as a
CL> closure in some sense already...

this is exactly what I have meant. If the C example I gave might be
optimized with LLVM engine, than `this' and lexical closures might be
boosted as well.

>> But, it is possible to generate individual code implementations
>> for every top-level call of `rec_func' to avoid big number of
>> extra `push'.

CL> In terms of LLVM you could certainly do this.  For example you could
CL> translate it to use an explicit stack:

CL> int rec_func(int x, int y) {
CL>   if(y<0) return x;
CL>   return y + rec_func(x, y-1); // should we really push x?
CL> }

then I have to dig LLVM docs about explicit stack :)

CL> Or you could just perform an aggressive dead code elimination pass
CL> which would realize that this function returns the same value for
CL> X no matter what the value of Y is.

you misunderstood this function a bit, but it is not important, dead
code elimination was out of my scope.

>> In terms of C++: there should be a possibility to regenerate
>> non-static member functions for a given instantiated object
>> of the classes where performance is critical, e.g. for classes
>> like valarray.

CL> Sure, but you still need the 'this' pointer, to know WHICH valarray you
CL> are talking about... ?

sure. But what if this `this' was set once for 1mio calls?
Today I have a lot heavy math function working with two spectra and
every time I have to think twice before making another member function
which is invoked in deeper stack frames.

In other words, just imagine the situation, when for a given object
really a lot of *its* members function are called without changing
`this'. Today compilers can't eliminate this _extra_ `this'. And real
C++ code has tendency to be slower.

I'd say it is not just a problem of current compilers. It is problem
of ultimate static compilation. In cases when `this' comes in run-time
even a super-smart static compilers can't recompile a function with
"built-in" `this'.

>> So, my questions are:
>> Q1. should/might the optimization like this be resolved at LLVM layer?

CL> Yes, LLVM is designed for spiffy optimizations like this.  :)

nicccce.

>> if "yes" then
>> Q2. is LLVM capable of doing things like that today?

CL> Nope, not yet.  Contributions are always appreciated though.  :)

now I have to prepare for sleeping, that's for sure. Probably this
nice patch from me doesn't come today :))

Have a nice day!

-- 
Best regards,
Valery A.Khamenya                       mailto:khamenya at mail.ru
Local Time: 23:01



From robert at mykland.com  Tue Aug 26 20:32:01 2003
From: robert at mykland.com (Robert Mykland)
Date: Tue Aug 26 20:32:01 2003
Subject: [LLVMdev] Seemingly ambiguous parameter lists
In-Reply-To: <Pine.LNX.4.44.0308261615160.13991-100000@nondot.org>
References: <5.2.1.1.0.20030826102557.00aaf3a8@mail.mykland.com>
Message-ID: <5.2.1.1.0.20030826182036.00abf428@mail.mykland.com>

Dear Chris,

I had a second question which is probably a dumb question, but here 
goes.  I'm just wondering how a function that has all varargs knows what to 
do.  I'm only familiar with the C style of varargs.  In that case you 
generally used one or more fixed parameters that told you how to interpret 
the rest.  Like the format string in printf, for example.  I suppose the 
function could look at a static variable somewhere to get this data.  That 
sounds messy.  Are these functions member functions with an implied first 
parameter perhaps?  If so, why not explicitly?

-- Robert.

At 04:17 PM 8/26/2003 -0500, Chris Lattner wrote:
>On Tue, 26 Aug 2003, Robert Mykland wrote:
> > And while we're on the subject to the type definitions table, what's the
> > difference between
> >
> > 0e 07 01 00
> > function returning Int ( Void )?  Function returning Int ( ... )?
>
>Void is not a legal argument.  The bytecode file uses the void marker as
>a way to store the ... for a varargs function.  IE, the declaration:
>
>void foo(void);
>
>in C, becomes the LLVM type 'void ()*' %foo.  The C declaration:
>
>void foo(...);
>
>becomes the LLVM type 'void (...)*' %foo, which is stored in the bytecode
>file (to be compact) as 'void (void)*'.
>
> > 0e 07 00
> > Function returning Int ()
>
>That is just 'int ()', function returning int, with no arguments.
>
> > I'm guessing the former really is a function returning Int ( ... ), but how
> > is the callee supposed to decode the parameter list?  I'm an old callee and
> > I don't know this new trick.  :-)
>
>Void is not a legal argument type, it is just used as a marker in the
>bytecode files.  :)
>
>-Chris
>
>--
>http://llvm.cs.uiuc.edu/
>http://www.nondot.org/~sabre/Projects/

Robert Mykland     Voice: (831) 462-6725 



From sabre at nondot.org  Tue Aug 26 20:40:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Tue Aug 26 20:40:01 2003
Subject: [LLVMdev] Seemingly ambiguous parameter lists
In-Reply-To: <5.2.1.1.0.20030826182036.00abf428@mail.mykland.com>
Message-ID: <Pine.LNX.4.44.0308262043080.16240-100000@nondot.org>

> I had a second question which is probably a dumb question, but here
> goes.

Not a problem.  :)

> I'm just wondering how a function that has all varargs knows what to do.
> I'm only familiar with the C style of varargs.  In that case you
> generally used one or more fixed parameters that told you how to
> interpret the rest.  Like the format string in printf, for example.  I
> suppose the function could look at a static variable somewhere to get
> this data.  That sounds messy.  Are these functions member functions
> with an implied first parameter perhaps?  If so, why not explicitly?

I assume you're talking about the va_start intrinsic:
http://llvm.cs.uiuc.edu/docs/LangRef.html#i_va_start

Basically here's the jist of it.  At least in C, it's impossible to make
use of varargs parameters in a function with zero declared arguments,
because the va_start macro requires the last argument as the parameter.
LLVM, however, is not necessarily tied down to C (we want to support
arbitrary languages), and adding the argument to va_start just makes
things needlessly more complex (what if the argument passed in is not the
last?)

The organization we have now allows us to put the error checking code in
the front-end for languages which do not allow this.  For a hypothetical
language which does allow varargs without a fixed, we support it just
fine.  :)

Essentially, these are the three reasons we don't have a restriction:

1. There MIGHT be some language that wants support for funny stuff like
   this.
2. It's easier to build the error checking into the C front-end, and then
   support the general case in LLVM.
3. Supporting the general case in LLVM is no harder than the "C" case.

Also, FWIW, it's very typical to define a varargs function with no
arguments in C.  In particular this function:

void foo();

Is varargs in C.  Contrast this with:

void foo(void);

And you are beginning to see a flavor of the fun stuff the C front-end has
to deal with.  :)  Of course, you can't USE the varargs in the body, so
the LLVM compiler transforms "void foo()" into "void foo(void)" when the
body is found, assuming it has no arguments.

-Chris


> At 04:17 PM 8/26/2003 -0500, Chris Lattner wrote:
> >On Tue, 26 Aug 2003, Robert Mykland wrote:
> > > And while we're on the subject to the type definitions table, what's the
> > > difference between
> > >
> > > 0e 07 01 00
> > > function returning Int ( Void )?  Function returning Int ( ... )?
> >
> >Void is not a legal argument.  The bytecode file uses the void marker as
> >a way to store the ... for a varargs function.  IE, the declaration:
> >
> >void foo(void);
> >
> >in C, becomes the LLVM type 'void ()*' %foo.  The C declaration:
> >
> >void foo(...);
> >
> >becomes the LLVM type 'void (...)*' %foo, which is stored in the bytecode
> >file (to be compact) as 'void (void)*'.
> >
> > > 0e 07 00
> > > Function returning Int ()
> >
> >That is just 'int ()', function returning int, with no arguments.
> >
> > > I'm guessing the former really is a function returning Int ( ... ), but how
> > > is the callee supposed to decode the parameter list?  I'm an old callee and
> > > I don't know this new trick.  :-)
> >
> >Void is not a legal argument type, it is just used as a marker in the
> >bytecode files.  :)
> >
> >-Chris
> >
> >--
> >http://llvm.cs.uiuc.edu/
> >http://www.nondot.org/~sabre/Projects/
>
> Robert Mykland     Voice: (831) 462-6725
>

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/



From vadve at cs.uiuc.edu  Tue Aug 26 22:59:01 2003
From: vadve at cs.uiuc.edu (Vikram S. Adve)
Date: Tue Aug 26 22:59:01 2003
Subject: [LLVMdev] repeated recursion with "frozen" arguments
In-Reply-To: <E19rfCT-000NcU-00.khamenya-mail-ru@f7.mail.ru>
Message-ID: <DJEFIDNMMMLFOJFAPLEMOECICGAA.vadve@cs.uiuc.edu>

The optimization you are describing is called procedure cloning, where the
body of a procedure is copied and then specialized for particular call
sites.  It is usually driven by interprocedural constant propagation, and
often by profiling to find which cases are frequent enough to make it
worthwhile (here the recursive calls would make both cases -- x=1 and x=2 --
worthwhile).

LLVM would be very well suited to this though we don't have any of the above
capabilities yet.

--Vikram
http://www.cs.uiuc.edu/~vadve


> -----Original Message-----
> From: llvmdev-admin at cs.uiuc.edu
> [mailto:llvmdev-admin at cs.uiuc.edu]On Behalf Of Валерий Хаменя
> Sent: Tuesday, August 26, 2003 9:54 AM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] repeated recursion with "frozen" arguments
>
>
> Hi llvm-devels,
>
> there is a very simple using case concerning LLVM and I am
> wondering whether it might be optimized at LLVM layer:
>
> //-----------
> int rec_func(int x, int y) {
>   if(y<0) return x;
>   return y + rec_func(x, y-1); // should we really push x?
> }
> void main() {
>   rec_func(1, 1000);
>   rec_func(2, 2000);
> }
> //-----------
>
> Guys, don't focus on a stupid mathematics beyond this function :)
> Please focus your attention at the fact, that argument `x'
> is once supplied at the top level calls in `main' and
> never changed anymore from within `rec_func' function.
>
> This example is just quite close to a "lexical closures" specifics.
>
> The similar things we have when we pass `this' pointer
> to non-static member functions in C++ (why should we
> pass `this' pointer always if it was not changed?).
>
> However, I guess in classical code generation approaches
> argument `x' (like `this' pointer) is always pushed into
> a stack with _every_ call.
>
> But, it is possible to generate individual code implementations
> for every top-level call of `rec_func' to avoid big number of
> extra `push'.
>
> In terms of C++: there should be a possibility to regenerate
> non-static member functions for a given instantiated object
> of the classes where performance is critical, e.g. for classes
> like valarray.
>
> So, my questions are:
>
> Q1. should/might the optimization like this be resolved at LLVM layer?
>
> if "yes" then
>
> Q2. is LLVM capable of doing things like that today?
>
> Thanks.
> --
> Valery
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From khamenya at mail.ru  Wed Aug 27 02:22:01 2003
From: khamenya at mail.ru (=?koi8-r?Q?=22=F7=C1=CC=C5=D2=C9=CA=20=E8=C1=CD=C5=CE=D1=22=20?=)
Date: Wed Aug 27 02:22:01 2003
Subject: [LLVMdev] repeated recursion with frozen arguments
In-Reply-To: <DJEFIDNMMMLFOJFAPLEMOECICGAA.vadve@cs.uiuc.edu>
Message-ID: <E19ruci-000DSO-00.khamenya-mail-ru@f19.mail.ru>

Hi LLVM-devels

> The optimization you are describing is called procedure cloning, 
> [...]
> LLVM would be very well suited to this though we don't have any 
> of the above capabilities yet.

oh, anyway nice to here that it might come.
I am looking towards LLVM abilities like that, because I believe
they could really boost the family of languages for functional 
programming. And I do believe that with a help of LLVM those
languages should bring better performance then classically 
used imperative languages with single static compilation.

--
Valery A.Khamenya


From khamenya at mail.ru  Wed Aug 27 03:41:02 2003
From: khamenya at mail.ru (=?koi8-r?Q?=22=F7=C1=CC=C5=D2=C9=CA=20=E8=C1=CD=C5=CE=D1=22=20?=)
Date: Wed Aug 27 03:41:02 2003
Subject: [LLVMdev] repeated recursion with =?koi8-r?Q?=22?=frozen=?koi8-r?Q?=22=20?=arguments
In-Reply-To: <Pine.LNX.4.44.0308261640200.14225-100000@nondot.org>
Message-ID: <E19rvvc-000OE0-00.khamenya-mail-ru@f22.mail.ru>

Hi LLVM-devels,

> Yup, I think I completely missed your point.  :)

funny, that if even so, I got two similar and concrete 
answers already:
"it is suitable for LLVM, though not implemented yet"
:)

> > generally you are right. But only generally :)
> > In particular, my example showed a feature of typical lexical closure.
> 
> Can you explain more about what you mean.  I don't think I understand.

I will try. But then perhaps I should separte statements in 
order to know where I was unclear.

S1. Example just shows simple phenomenon when every recursive 
    (i.e. not from main) call of function `rec_func' does 
    *not* change variable `x' anymore. It means, that every
    recursive call just makes extra/redundant copy of the
    `x'.

S2. Theoretically this redundant copy might be eliminated.
    The idea is simple: at first (i.e. non-recursive) call 
    generate `rec_func' code which does not push `x' on 
    the stack because it will remain the same from the 
    first non-recursive call. For example initial 
    non-recursive call `rec_func(1, 1000)' should be
    instantiated as:

    int rec_func(int y) {
      if(y<0) return 1;
      return y + rec_func(y-1);
    }

    so, this instantiation of function `rec_func' doesn't
    need to push `x' on stack anymore.

S3. This example is just a C-analogy of how pushing `this'
    onto stack might be eliminated. Just think of `x' as 
    it would be `this', and think of `rec_func' as it 
    would be a non-static member function. For example:

struct Math {

  Math(int _y) : y(_y) {}

  int rec_func() {
    if(y<0) return 42; 
    y--;
    return y 
           + rec_func(); // here `this' will be the same 
                            // up to destruction of the object
  }

};

void main() {
  Math m1(1000), m2(2000);

  m1.rec_func(); // initial `this' is supplied here and will 
                 // be the same for evry next call of rec_func
                 // from this object

  m2.rec_func(); // as above,
                 // initial `this' is supplied here and will 
                 // remain the same for evry next call of 
                 // rec_func from this object
}  

S4. in optimization of C-example (see S2.) we just made a 
    lexical closure in respet to variable `x'. (And by analogy, 
    in C++ example we could consider similar optimization which 
     in a sense is a lexical closure in respect to `this')

Now, Chris, please locate the point where I am unclear :)

> varray's do not have any recursive function calls, and the 
> methods tend to be simple.  For that reason, they are 
> typically all inlined, eliminating
> the parameter passing completely...

you are right.

However, my classes for spectra analysis I deal with should be as 
fast as valarray is, but they may not be so oversimplified
as valarray... I have to break my fat non-static member functions 
into smaller pieces and those simple pieces are called a lot 
of times with the same `this'. So, the `valarray'-like classes 
in real life are not always that nice.


> I really am not sure I understand what transformation you are proposing.
> Can you elaborate more?  :)

perhaps, I showed the point above. It looks like 
Vikram S. Adve got my point already, and if he is near 
you then probably he could reformulate my thoughts in 
correct English just orally without typing :)

Kind regards,
---
Valery



From sabre at nondot.org  Wed Aug 27 09:16:01 2003
From: sabre at nondot.org (Chris Lattner)
Date: Wed Aug 27 09:16:01 2003
Subject: [LLVMdev] repeated recursion with =?koi8-r?Q?=22?=frozen=?koi8-r?Q?=22=20?=arguments
In-Reply-To: <E19rvvc-000OE0-00.khamenya-mail-ru@f22.mail.ru>
Message-ID: <Pine.LNX.4.44.0308270920140.26496-100000@nondot.org>

On Wed, 27 Aug 2003, [koi8-r] "������� ������"  wrote:
> funny, that if even so, I got two similar and concrete
> answers already:
> "it is suitable for LLVM, though not implemented yet"
> :)

:)

> S2. Theoretically this redundant copy might be eliminated.
>     The idea is simple: at first (i.e. non-recursive) call
>     generate `rec_func' code which does not push `x' on
>     the stack because it will remain the same from the
>     first non-recursive call. For example initial
>     non-recursive call `rec_func(1, 1000)' should be
>     instantiated as:

Ok, Vikram is right.  This is known as procedure cloning, where the
compiler makes a specialized version of the function for an invocation
with constant arguments (thus making it so you don't have to pass the
arguments).

> S3. This example is just a C-analogy of how pushing `this'
>     onto stack might be eliminated. Just think of `x' as
>     it would be `this', and think of `rec_func' as it
>     would be a non-static member function. For example:

Ok, I see why I was confused here.  The problem is that a particular
"this" is not, in general, a compile time constant: if the object is
allocated dynamically on the stack or heap, the static compiler doesn't
know which value to specialize with.  Obviously a dynamic compiler could
though...

> S4. in optimization of C-example (see S2.) we just made a
>     lexical closure in respet to variable `x'. (And by analogy,
>     in C++ example we could consider similar optimization which
>      in a sense is a lexical closure in respect to `this')

Ok, I understand now.  When I think of lexical closures, I think if a
piece of memory which holds the variables used by a block of code, coupled
with a generic version of the code.  Converting a "this" pointer to use
this style of closure means that you have to add a closure pointer  :)

So, in sum, yes, LLVM is a good representation to do this kind of thing
on.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/





From khamenya at mail.ru  Wed Aug 27 12:42:01 2003
From: khamenya at mail.ru (Valery A.Khamenya)
Date: Wed Aug 27 12:42:01 2003
Subject: [LLVMdev] repeated recursion with "frozen" arguments
In-Reply-To: <Pine.LNX.4.44.0308270920140.26496-100000@nondot.org>
References: <Pine.LNX.4.44.0308270920140.26496-100000@nondot.org>
Message-ID: <8420906011.20030827194129@mail.ru>

Hello Chris,

Wednesday, August 27, 2003, 4:27:21 PM, you wrote:

CL> Ok, Vikram is right.  This is known as procedure cloning, where the
CL> compiler makes a specialized version of the function for an invocation
CL> with constant arguments (thus making it so you don't have to pass the
CL> arguments).

just one remark: it would be better to say "known arguments" instead
of "constant arguments" :)

CL> Ok, I see why I was confused here.  The problem is that a particular
CL> "this" is not, in general, a compile time constant: if the object is
CL> allocated dynamically on the stack or heap, the static compiler doesn't
CL> know which value to specialize with.  Obviously a dynamic compiler could
CL> though...

exactly :)

CL> Ok, I understand now.  When I think of lexical closures, I think if a
CL> piece of memory which holds the variables used by a block of code, coupled
CL> with a generic version of the code.  Converting a "this" pointer to use
CL> this style of closure means that you have to add a closure pointer  :)

:)

CL> So, in sum, yes, LLVM is a good representation to do this kind of thing
CL> on.  :)

is LLVM a kind of paradise promises?..
I should definitely check this out :)

-- 
Best regards,
Valery A.Khamenya                       mailto:khamenya at mail.ru
Local Time: 19:36



From brukman at uiuc.edu  Thu Aug 28 16:44:05 2003
From: brukman at uiuc.edu (Misha Brukman)
Date: Thu Aug 28 16:44:05 2003
Subject: [LLVMdev] The Great LLVM Tool Renaming
Message-ID: <20030828214315.GA30811@zion>

Howdy, oh LLVMers!

As you may or may not have noticed, the LLVM tool `as' has a problematic
name that conflicts with the standard system assembler. This poses a
problem for programs such as `gcc' which searches the path for a
suitable assembler -- it may find the LLVM assembler instead of the
native version, causing compilation errors.

Thus, I am undertaking the project of renaming LLVM tools to have the
`llvm-' prefix. Initially, this will affect `as' and will extend to
`dis', the disassembler. 

What will happen is as follows:

* as  -> llvm-as
* dis -> llvm-dis

I am making a COPY of the tools/as and tools/dis directories, so a full
build will build a copy of `as' as well as `llvm-as', and same for `dis'
and `llvm-dis'.

This is for compatibility of hard-coded `as' and `dis' in automated
regression tests and elsewhere in documentation, etc. These will be
converted in due time, in the mean time, this is the upgrade path:

* Directories are now copied
* The `obsolete' directories will go away in a week or two, and you will
  be forced to use llvm-as and llvm-dis, but note that this is for your
  benefit! :)

If this is unclear or if you have questions/suggestions, we are all
ears.

-- 
Misha Brukman :: http://misha.brukman.net


From dcrowe at crhc.uiuc.edu  Thu Aug 28 17:22:01 2003
From: dcrowe at crhc.uiuc.edu (David Crowe)
Date: Thu Aug 28 17:22:01 2003
Subject: [LLVMdev] cross-compilation
In-Reply-To: <20030808170005.24276.21171.Mailman@dcs-server2.cs.uiuc.edu>
References: <20030808170005.24276.21171.Mailman@dcs-server2.cs.uiuc.edu>
Message-ID: <1062091009.29483.18.camel@glamdring.crowe.com>

LLVM,

Is it possible to cross compile on an x86 platform to a sparc binary?

Thanks,
Dave



From sabre at nondot.org  Thu Aug 28 17:25:02 2003
From: sabre at nondot.org (Chris Lattner)
Date: Thu Aug 28 17:25:02 2003
Subject: [LLVMdev] cross-compilation
In-Reply-To: <1062091009.29483.18.camel@glamdring.crowe.com>
Message-ID: <Pine.LNX.4.44.0308281734140.14776-100000@nondot.org>

On 28 Aug 2003, David Crowe wrote:

> LLVM,
> Is it possible to cross compile on an x86 platform to a sparc binary?

I think that all of the LLVM tools work in cross compilation
configurations.  The only questionable one is the C/C++ frontend, which
you would have to rebuild for yourself.  LLC and the C backend can
generate sparc output on X86 with no problem.  The JIT obviously will not
work.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/