using dsa from llvm-poolalloc

Project Infrastructure LLVM Dev List Archives
#1

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

#2

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.

#3

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

#4

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.

#5

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.

#6

Devang Patel 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.

#7

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

#8

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

#9

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

#10

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? :slight_smile:

-Chris