using dsa from llvm-poolalloc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

using dsa from llvm-poolalloc

Ryan M. Lefever
I have a few questions on using dsa now that it has been moved out of
llvm.  I have llvm -r release_19 checked out from cvs, and
llvm-poolalloc -r release_19 checked out from cvs into the projects
directory, as John Criswell previously suggested.

1) I have some compiler transforms that I'm writing that use DSA. They
can no longer find the header files for DSA. My transforms are located
in their own directory, outside of llvm.  I have set everything up by
copying the autoconf directory from the sample project into the
directory for my transforms.  Is there a way that I can specify the path
to the DSA include files when I run AutoRegen.sh from the autoconf
directory or the configure script generated by AutoRegen.sh, so that the
DSA include files will be searched when compiling my code?

2) For those that work on llvm-poolalloc, is their a way to compile
doxygen for llvm-poolalloc?

3) For those that work on llvm-poolalloc, John Criswell previously
suggested using cvs -r release_19 of llvm, and cvs -r release_19 of
llvm-poolalloc.  If I want to get the latest changes to llvm-poolalloc
which of the following should I do?  (A) Stick with cvs -r release_19 of
llvm and update to the latest version of llvm-poolalloc using cvs update
-A inside the projects/llvm-poolalloc directory.  (B) Update llvm and
llvm-poolalloc both to the latest versions.  (C) Some other option.

Thanks,
Ryan

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

John Criswell
Ryan M. Lefever wrote:

> I have a few questions on using dsa now that it has been moved out of
> llvm.  I have llvm -r release_19 checked out from cvs, and
> llvm-poolalloc -r release_19 checked out from cvs into the projects
> directory, as John Criswell previously suggested.
>
> 1) I have some compiler transforms that I'm writing that use DSA. They
> can no longer find the header files for DSA. My transforms are located
> in their own directory, outside of llvm.  I have set everything up by
> copying the autoconf directory from the sample project into the
> directory for my transforms.  Is there a way that I can specify the
> path to the DSA include files when I run AutoRegen.sh from the
> autoconf directory or the configure script generated by AutoRegen.sh,
> so that the DSA include files will be searched when compiling my code?

First, the DSA header files are within a different relative directory.  
In your source file, you should write:

#include <dsa/headerfilename.h>

instead of:

#include <llvm/Analysis/DataStructure/headerfilename.h>

Second, you need to pass a -I<directory> option to gcc so that it knows
where to find these header files.  The easiest thing to do is to
hard-code the path in your Makefile.  To do that, add the following 3
lines to your Makefile.common in your project:

CFLAGS += -I<directory to llvm-poolalloc>/include
CXXFLAGS += -I<directory to llvm-poolalloc>/include
CPPFLAGS += -I<directory to llvm-poolalloc>/include

(Note: I don't know if all of these lines are strictly necessary, but it
works for me.)

A better approach is to create --with-poolallocsrcdir and
--with-poolallocobjdir options that can specify the path to the
llvm-poolalloc source and object code at configuration time.  The
autoconf/configure.ac file in the llvm-poolalloc project has an example
of this (except it's the --with-safecodesrc option).  If you need help
setting that up, please let me know, and I can help.

>
> 2) For those that work on llvm-poolalloc, is their a way to compile
> doxygen for llvm-poolalloc?

Not that I'm aware of.

>
> 3) For those that work on llvm-poolalloc, John Criswell previously
> suggested using cvs -r release_19 of llvm, and cvs -r release_19 of
> llvm-poolalloc.  If I want to get the latest changes to llvm-poolalloc
> which of the following should I do?  (A) Stick with cvs -r release_19
> of llvm and update to the latest version of llvm-poolalloc using cvs
> update -A inside the projects/llvm-poolalloc directory.  (B) Update
> llvm and llvm-poolalloc both to the latest versions.  (C) Some other
> option.

(C) Some other option.

I recommend that you stick with the release_19 branch of both llvm and
llvm-poolalloc.  I and others are actively using these branches, so
llvm-poolalloc bug fixes will most likely be made to this branch in
addition to mainline CVS for the forseeable future.  The release_19
branch of llvm-poolalloc is designed to always work with the release_19
branch of LLVM, which has a fixed API and bytecode format.

Someday, the CVS HEAD llvm-poolalloc will compile against CVS HEAD llvm,
but it doesn't at the moment.  LLVM has undergone major changes between
1.9 and what will be 2.0, and I was spending more time updating
llvm-poolalloc to handle the new API changes than I was using it for my
project.  We plan to get llvm-poolalloc working with LLVM 2.0 once the
new LLVM API stabilizes and we have the time to do the update.

-- John T.

>
> Thanks,
> Ryan
>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

Tanya Lattner-2

> I recommend that you stick with the release_19 branch of both llvm and
> llvm-poolalloc.  I and others are actively using these branches, so
> llvm-poolalloc bug fixes will most likely be made to this branch in
> addition to mainline CVS for the forseeable future.  The release_19
> branch of llvm-poolalloc is designed to always work with the release_19
> branch of LLVM, which has a fixed API and bytecode format.

I did not realize that you guys were checking in changes to the release_19
branch. I have to disagree with this as release_19 is supposed to match
the release 1.9 that we have on our website. This release has been tested
on all platforms (that we support) and by changing the files in CVS I can
no longer guarantee that same level of quality if someone checks out
release_19. We do allow and suggest that people check out the release_19
from CVS (in the Getting Started Guide) so they should be getting the same
files as in the tar.

I would suggest creating your own branch if you do not plan to keep up
with mainline cvs.

In the future, I would hope that you would talk to me (the Release
Manager) or email the list about changes to the policy regarding the
release branches.

-Tanya

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

John Criswell
Tanya M. Lattner wrote:

>>I recommend that you stick with the release_19 branch of both llvm and
>>llvm-poolalloc.  I and others are actively using these branches, so
>>llvm-poolalloc bug fixes will most likely be made to this branch in
>>addition to mainline CVS for the forseeable future.  The release_19
>>branch of llvm-poolalloc is designed to always work with the release_19
>>branch of LLVM, which has a fixed API and bytecode format.
>>    
>>
>
>I did not realize that you guys were checking in changes to the release_19
>branch. I have to disagree with this as release_19 is supposed to match
>the release 1.9 that we have on our website. This release has been tested
>on all platforms (that we support) and by changing the files in CVS I can
>no longer guarantee that same level of quality if someone checks out
>release_19. We do allow and suggest that people check out the release_19
>from CVS (in the Getting Started Guide) so they should be getting the same
>files as in the tar.
>  
>

I don't believe I've changed any policy that we've had (at least, not
significantly), and I think you may misunderstand what I am changing and
where I'm making the changes.

Here's my explanation of what I did:

1) According to the policy I set forth when I did release management,
there is a difference between RELEASE_19 and release_19.  RELEASE_19 is
a tag that denotes what we released in LLVM 1.9; it should never
change.  The release_19 tag is a branch tag that denotes the branch for
the 1.9.x releases.  To date, we've only created one release per release
branch, but we should be able to make subsequent releases on the branch
(e.g. 1.9.1, 1.9.2, etc) if we want.

The purpose of this policy was to ensure that we could make bug fixes to
multiple LLVM releases should the need arise.

2) I marked RELEASE_19 before changing anything in the release_19 branch
of llvm (you never tagged RELEASE_19).  Assuming no one else modified
anything in the release_19 branch, RELEASE_19 represents what is in the
LLVM 1.9 tarball.

3) The only changes in the llvm release_19 branch is the removal of DSA
and (maybe) some minor autoconf changes.  I did this to ease merges on
DSA between the release_19 branch and mainline of the llvm-poolalloc CVS
module.

4) The only new development I've been doing is in the release_19 branch
of the llvm-poolalloc and safecode CVS modules.  llvm-poolalloc is, as
far as I can tell, not part of the LLVM releases, and safecode is still
an internal project, so I don't think I've broken any of our release
policies by creating and developing in the release_19 branches for these
two CVS modules.

>I would suggest creating your own branch if you do not plan to keep up
>with mainline cvs.
>
>In the future, I would hope that you would talk to me (the Release
>Manager) or email the list about changes to the policy regarding the
>release branches.
>  
>
I don't think I've changed any policies of which I am aware.  However, I
do apologize for not asking you whether you had changed the policy when
I noticed that the RELEASE_19 tag was missing; I probably should have
asked you first before fixing it.

-- John T.

>-Tanya
>
>_______________________________________________
>LLVM Developers mailing list
>[hidden email]         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>  
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

Devang Patel

On Feb 13, 2007, at 11:08 AM, John T. Criswell wrote:

there is a difference between RELEASE_19 and release_19.


I have not tried, but I won't be surprised if CVS itself gets confused between this two on systems like Darwin which is case insensitive but case preserving.

-
Devang

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: release tag policy

Chris Lattner
In reply to this post by John Criswell
On Tue, 13 Feb 2007, John T. Criswell wrote:
>>> I recommend that you stick with the release_19 branch of both llvm and
>>> llvm-poolalloc.  I and others are actively using these branches, so
>>> llvm-poolalloc bug fixes will most likely be made to this branch in
>>> addition to mainline CVS for the forseeable future.  The release_19
>>> branch of llvm-poolalloc is designed to always work with the release_19
>>> branch of LLVM, which has a fixed API and bytecode format.

>> I did not realize that you guys were checking in changes to the release_19
>> branch. I have to disagree with this as release_19 is supposed to match
>> the release 1.9 that we have on our website. This release has been tested

> 1) According to the policy I set forth when I did release management,
> there is a difference between RELEASE_19 and release_19.  RELEASE_19 is
> a tag that denotes what we released in LLVM 1.9; it should never
> change.  The release_19 tag is a branch tag that denotes the branch for
> the 1.9.x releases.  To date, we've only created one release per release
> branch, but we should be able to make subsequent releases on the branch
> (e.g. 1.9.1, 1.9.2, etc) if we want.

I think the real problem here is that the current policy is either not
documented, or is inadequately documented.  Please pick a policy and stick
with it, but describe it somewhere in the release guide or in the new
'Developer Policy' section.

I think having a sub-release branch makes sense for dot releases.

> 3) The only changes in the llvm release_19 branch is the removal of DSA
> and (maybe) some minor autoconf changes.  I did this to ease merges on
> DSA between the release_19 branch and mainline of the llvm-poolalloc CVS
> module.

Regardless of the policy, I don't think this is acceptable.  Your stated
goal for the release_19 branch is for it to be a host for 1.9.1.  Removing
an entire library does not sound like a ".1" change.  If you wanted to do
this, having a separate branch would make sense, instead of taking over
the 'release' branch.

I don't care about correcting this for the 1.9 release, and I don't really
think that overloading RELEASE_19 and release_19 is a good idea, but
please work together and figure out a policy that makes sense.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

John Criswell
In reply to this post by Devang Patel
Devang Patel wrote:

>
> On Feb 13, 2007, at 11:08 AM, John T. Criswell wrote:
>
>> there is a difference between RELEASE_19 and release_19.
>>
>
> I have not tried, but I won't be surprised if CVS itself gets confused
> between this two on systems like Darwin which is case insensitive but
> case preserving.

I don't see why that would be a problem.  These are not filenames; they
are CVS labels.  However, if someone finds it to be a problem, the
convention can be changed (I suspect it probably will be changed).

-- John T.

>
> -
> Devang
>
>------------------------------------------------------------------------
>
>_______________________________________________
>LLVM Developers mailing list
>[hidden email]         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>  
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: release tag policy

John Criswell
In reply to this post by Chris Lattner
Chris Lattner wrote:

>On Tue, 13 Feb 2007, John T. Criswell wrote:
>  
>
>>>>I recommend that you stick with the release_19 branch of both llvm and
>>>>llvm-poolalloc.  I and others are actively using these branches, so
>>>>llvm-poolalloc bug fixes will most likely be made to this branch in
>>>>addition to mainline CVS for the forseeable future.  The release_19
>>>>branch of llvm-poolalloc is designed to always work with the release_19
>>>>branch of LLVM, which has a fixed API and bytecode format.
>>>>        
>>>>
>
>  
>
>>>I did not realize that you guys were checking in changes to the release_19
>>>branch. I have to disagree with this as release_19 is supposed to match
>>>the release 1.9 that we have on our website. This release has been tested
>>>      
>>>
>
>  
>
>>1) According to the policy I set forth when I did release management,
>>there is a difference between RELEASE_19 and release_19.  RELEASE_19 is
>>a tag that denotes what we released in LLVM 1.9; it should never
>>change.  The release_19 tag is a branch tag that denotes the branch for
>>the 1.9.x releases.  To date, we've only created one release per release
>>branch, but we should be able to make subsequent releases on the branch
>>(e.g. 1.9.1, 1.9.2, etc) if we want.
>>    
>>
>
>I think the real problem here is that the current policy is either not
>documented, or is inadequately documented.  Please pick a policy and stick
>with it, but describe it somewhere in the release guide or in the new
>'Developer Policy' section.
>  
>
Agreed.

>I think having a sub-release branch makes sense for dot releases.
>
>  
>
>>3) The only changes in the llvm release_19 branch is the removal of DSA
>>and (maybe) some minor autoconf changes.  I did this to ease merges on
>>DSA between the release_19 branch and mainline of the llvm-poolalloc CVS
>>module.
>>    
>>
>
>Regardless of the policy, I don't think this is acceptable.  Your stated
>goal for the release_19 branch is for it to be a host for 1.9.1.  Removing
>an entire library does not sound like a ".1" change.  If you wanted to do
>this, having a separate branch would make sense, instead of taking over
>the 'release' branch.
>  
>
Okay.

>I don't care about correcting this for the 1.9 release, and I don't really
>think that overloading RELEASE_19 and release_19 is a good idea, but
>please work together and figure out a policy that makes sense.
>  
>
Switching to another naming convention might be a good idea; it seems
it's causing confusion.

Since Tanya is the release manager now, I'll defer to her judgement.  If
you'd like me to draft up the conventions I used, please let me know.

-- John T.

>-Chris
>
>  
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: using dsa from llvm-poolalloc

Tanya Lattner-2
In reply to this post by John Criswell

>> I did not realize that you guys were checking in changes to the release_19
>> branch. I have to disagree with this as release_19 is supposed to match
>> the release 1.9 that we have on our website. This release has been tested
>> on all platforms (that we support) and by changing the files in CVS I can
>> no longer guarantee that same level of quality if someone checks out
>> release_19. We do allow and suggest that people check out the release_19
>> from CVS (in the Getting Started Guide) so they should be getting the same
>> files as in the tar.
>>
>>
>
> I don't believe I've changed any policy that we've had (at least, not
> significantly), and I think you may misunderstand what I am changing and
> where I'm making the changes.

Ok. I think there are 2 issues here.

First, I was not aware that I was to tag the release branch as it wasn't a
part of the how to release LLVM document. So thats is my mistake. Since we
had never done X.X.X releases (lets call them subreleases) it never became
an issue. In the future, we may decide to do this, so you are right that
it makes sense to tag the release branch and work from there. I think we
need to figure out how we want to do this as RELEASE_19 may be a bit
confusing since its the same as the release branch name. We should also
discuss if we are branching off the branch for subreleases. Hopefully that
made sense.

Second, for the subreleases we should only be checking in critical
patches. This is where it gets a bit tricky because we have no formal
policy in place as to what is deemed critical because we have never had a
need to do subreleases. I think it would be better if the pool-alloc team
had a branch off the release branch to do your development. That way you
can make any changes you wish and merge in any patches you wish without
having to have them "formally" approved (whatever the LLVM team defines
that to be).

What do you think?

-Tanya


>
> Here's my explanation of what I did:
>
> 1) According to the policy I set forth when I did release management,
> there is a difference between RELEASE_19 and release_19.  RELEASE_19 is
> a tag that denotes what we released in LLVM 1.9; it should never
> change.  The release_19 tag is a branch tag that denotes the branch for
> the 1.9.x releases.  To date, we've only created one release per release
> branch, but we should be able to make subsequent releases on the branch
> (e.g. 1.9.1, 1.9.2, etc) if we want.
>
> The purpose of this policy was to ensure that we could make bug fixes to
> multiple LLVM releases should the need arise.
>
> 2) I marked RELEASE_19 before changing anything in the release_19 branch
> of llvm (you never tagged RELEASE_19).  Assuming no one else modified
> anything in the release_19 branch, RELEASE_19 represents what is in the
> LLVM 1.9 tarball.
>
> 3) The only changes in the llvm release_19 branch is the removal of DSA
> and (maybe) some minor autoconf changes.  I did this to ease merges on
> DSA between the release_19 branch and mainline of the llvm-poolalloc CVS
> module.
>
> 4) The only new development I've been doing is in the release_19 branch
> of the llvm-poolalloc and safecode CVS modules.  llvm-poolalloc is, as
> far as I can tell, not part of the LLVM releases, and safecode is still
> an internal project, so I don't think I've broken any of our release
> policies by creating and developing in the release_19 branches for these
> two CVS modules.
>
>> I would suggest creating your own branch if you do not plan to keep up
>> with mainline cvs.
>>
>> In the future, I would hope that you would talk to me (the Release
>> Manager) or email the list about changes to the policy regarding the
>> release branches.
>>
>>
> I don't think I've changed any policies of which I am aware.  However, I
> do apologize for not asking you whether you had changed the policy when
> I noticed that the RELEASE_19 tag was missing; I probably should have
> asked you first before fixing it.
>
> -- John T.
>
>> -Tanya
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: release tag policy

Chris Lattner
In reply to this post by John Criswell
On Tue, 13 Feb 2007, John T. Criswell wrote:
>> I don't care about correcting this for the 1.9 release, and I don't really
>> think that overloading RELEASE_19 and release_19 is a good idea, but
>> please work together and figure out a policy that makes sense.
>>
>>
> Switching to another naming convention might be a good idea; it seems
> it's causing confusion.

I agree.

> Since Tanya is the release manager now, I'll defer to her judgement.  If
> you'd like me to draft up the conventions I used, please let me know.

I propose that Tanya write up a summary of the 'rules' and pick a naming
convention, sending it to this list.  That way she can get feedback from
you (and others) and the wording can be folded into the new Developer
Policy doc.

Sound reasonable Tanya?

Isn't it great that LLVM is growing to the point where people care about
these things? :)

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev