Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]

[Vladimir_A_Merzliako]

Hi!

In current LLVM CVS:

llvm/projects/Stacker/Makefile.common.in
llvm/projects/sample/Makefile.common.in
llvm-java/llvm-java/Makefile.common.in

have line:
include $(LLVM_OBJ_ROOT)/Makefile.common

that have line:
include $(LLVM_OBJ_ROOT)/Makefile.config

(also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in)

and

llvm/Makefile.config.in have lines:

INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs

But all this projects (LLVM, Stacker, sample, llvm-java) have
autoconf/install-sh and autoconf/mkinstalldirs in own sources.

I think at building, for example, llvm-java use
llvm-java/autoconf/install-sh is more correct (synchronized version with
other autoconf files and configure in project sources)

Is patch replacing

INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs

by

INSTALL_SH := $(PROJ_SRC_ROOT)/autoconf/install-sh
MKDIR := $(PROJ_SRC_ROOT)/autoconf/mkinstalldirs

acceptable?

LLVM (including Stacker, sample), llvm-java build and installed with patch and without problems.
llvm-test have same install-sh and mkinstalldirs files as Stacker.

Vladimir

Makefile.config.in.patch (572 Bytes)

[Reid]

Personally, I don't think LLVM projects should need much in the way of
autoconf stuff. They certainly don't need to replicate things like
install-sh and mkinstalldirs. I'd vote for taking these out of the
projects rather than making the makefiles deal with them. I think in
most cases these are just historical artifacts that have been with the
projects since long before the new Makefile.rules of last fall.

More below ..

Hi!

In current LLVM CVS:

llvm/projects/Stacker/Makefile.common.in
llvm/projects/sample/Makefile.common.in
llvm-java/llvm-java/Makefile.common.in

have line:
include $(LLVM_OBJ_ROOT)/Makefile.common

that have line:
include $(LLVM_OBJ_ROOT)/Makefile.config

(also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in)

This is all quite normal. Note that llvm-test is a little bit weird
because it does not use $(LLVM_OBJ_ROOT)/Makefile.rules, it has its own
Makefile.rules

and

llvm/Makefile.config.in have lines:

INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs

But all this projects (LLVM, Stacker, sample, llvm-java) have
autoconf/install-sh and autoconf/mkinstalldirs in own sources.

Which they probably shouldn't have. I'd vote for removing these files
from the projects.

I think at building, for example, llvm-java use
llvm-java/autoconf/install-sh is more correct (synchronized version with
other autoconf files and configure in project sources)

I think that it just leads to confusion. LLVM should provide the core
set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the
makefile system (since LLVM owns the makefile system). LLVM projects
that want to use this system should use its facilities and not override
them. If someone doesn't want to do that, then it shouldn't be regarded
as an LLVM project (in the makefile sense).

Is patch replacing

INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs

by

INSTALL_SH := $(PROJ_SRC_ROOT)/autoconf/install-sh
MKDIR := $(PROJ_SRC_ROOT)/autoconf/mkinstalldirs

acceptable?

Its acceptable but I don't think its what we ultimately want to do. I'd
rather everyone use a consistent version of install-sh and mkinstalldirs
(the ones provided by llvm/autoconf) rather than every project rolling
their own.

LLVM (including Stacker, sample), llvm-java build and installed with patch
and without problems.
llvm-test have same install-sh and mkinstalldirs files as Stacker.

Sure, my argument isn't current correctness, its future correctness.
What happens when we update the LLVM tools in the future and they are no
longer compatible with the ones in the projects? The answer is that the
projects break. If we make the projects use the new tools (as currently
done with LLVM makefiles), we limit the number of things that have to
change and ensure that we don't break the projects after changes.

On a larger scale, I have toyed with the idea of making the LLVM
Makefile system just a separate public domain software project that
anyone can use. But, not sure how everyone would feel about that.

Reid.

[clattner]

Personally, I don't think LLVM projects should need much in the way of
autoconf stuff. They certainly don't need to replicate things like
install-sh and mkinstalldirs. I'd vote for taking these out of the
projects rather than making the makefiles deal with them. I think in
most cases these are just historical artifacts that have been with the
projects since long before the new Makefile.rules of last fall.

I agree.

llvm/Makefile.config.in have lines:

INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs

But all this projects (LLVM, Stacker, sample, llvm-java) have
autoconf/install-sh and autoconf/mkinstalldirs in own sources.

Which they probably shouldn't have. I'd vote for removing these files
from the projects.

Agreed. If projects choose to use our makefiles, they can know and use the main copies of these that LLVM provides.

I think at building, for example, llvm-java use
llvm-java/autoconf/install-sh is more correct (synchronized version with
other autoconf files and configure in project sources)

I think that it just leads to confusion. LLVM should provide the core
set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the
makefile system (since LLVM owns the makefile system). LLVM projects
that want to use this system should use its facilities and not override
them. If someone doesn't want to do that, then it shouldn't be regarded
as an LLVM project (in the makefile sense).

However, projects should continue to be able to have their own configure scripts. It would be nice if this was optional though!

On a larger scale, I have toyed with the idea of making the LLVM
Makefile system just a separate public domain software project that
anyone can use. But, not sure how everyone would feel about that.

If it didn't make things any uglier, I personally wouldn't have a problem with it. They should be significantly refactored first though.

-Chris

[Reid]

> Personally, I don't think LLVM projects should need much in the way of
> autoconf stuff. They certainly don't need to replicate things like
> install-sh and mkinstalldirs. I'd vote for taking these out of the
> projects rather than making the makefiles deal with them. I think in
> most cases these are just historical artifacts that have been with the
> projects since long before the new Makefile.rules of last fall.

I agree.

Okay, I'll make that happen

>> llvm/Makefile.config.in have lines:
>>
>> INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
>> MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs
>>
>> But all this projects (LLVM, Stacker, sample, llvm-java) have
>> autoconf/install-sh and autoconf/mkinstalldirs in own sources.
>
> Which they probably shouldn't have. I'd vote for removing these files
> from the projects.

Agreed. If projects choose to use our makefiles, they can know and use
the main copies of these that LLVM provides.

Right.

>> I think at building, for example, llvm-java use
>> llvm-java/autoconf/install-sh is more correct (synchronized version with
>> other autoconf files and configure in project sources)
>
> I think that it just leads to confusion. LLVM should provide the core
> set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the
> makefile system (since LLVM owns the makefile system). LLVM projects
> that want to use this system should use its facilities and not override
> them. If someone doesn't want to do that, then it shouldn't be regarded
> as an LLVM project (in the makefile sense).

However, projects should continue to be able to have their own configure
scripts. It would be nice if this was optional though!

It already is optional. Projects don't even have to have a
Makefile.config. They just need a Makefile.common that all the sub
directories include and Makefile.common just needs to pick up llvm's
Makefile.config and Makefile.rules (via LLVM's Makefile.common).
The only reason we continue to have configured Makefile.config and
configure scripts is (a) because the project truly needs configurable
options or (b) that's just the way the project was before configuration
was made optional.

> On a larger scale, I have toyed with the idea of making the LLVM
> Makefile system just a separate public domain software project that
> anyone can use. But, not sure how everyone would feel about that.

If it didn't make things any uglier, I personally wouldn't have a problem
with it. They should be significantly refactored first though.

Yes, I was thinking about doing the refactoring as a separate project
and then have LLVM use that project. The *only* issue with this approach
is that we might loose a modicum of control if many others used the
makefile system. However, that could also benefit us by getting
new/better features out of the makefile system. Anyway, this isn't a
decision we need to make right now. If I or someone else gets the
impetus to polish everything up, make it modular, document it properly,
etc. then so be it. This could be a natural result of projects like XPS
or other large LLVM based projects wanting to use a makefile system that
isn't necessarily tied to LLVM. Anyway, lets cross that bridge when we
get there.

Reid

[clattner]

Sounds good.

-Chris

[Vladimir_A_Merzliako]

> > Personally, I don't think LLVM projects should need much in the way of
> > autoconf stuff. They certainly don't need to replicate things like
> > install-sh and mkinstalldirs. I'd vote for taking these out of the
> > projects rather than making the makefiles deal with them. I think in
> > most cases these are just historical artifacts that have been with the
> > projects since long before the new Makefile.rules of last fall.
>
> I agree.

Okay, I'll make that happen

> >> llvm/Makefile.config.in have lines:
> >>
> >> INSTALL_SH := $(LLVM_SRC_ROOT)/autoconf/install-sh
> >> MKDIR := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs
> >>
> >> But all this projects (LLVM, Stacker, sample, llvm-java) have
> >> autoconf/install-sh and autoconf/mkinstalldirs in own sources.
> >
> > Which they probably shouldn't have. I'd vote for removing these files
> > from the projects.
>
> Agreed. If projects choose to use our makefiles, they can know and use
> the main copies of these that LLVM provides.

Right.

In current state removing this files break $(PROJ_SRC_ROOT)/configure run:
"configure: error: cannot find install-sh or install.sh in autoconf ../src/autoconf"

> >> I think at building, for example, llvm-java use
> >> llvm-java/autoconf/install-sh is more correct (synchronized version > >> with
> >> other autoconf files and configure in project sources)
> >
> > I think that it just leads to confusion. LLVM should provide the core
> > set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the
> > makefile system (since LLVM owns the makefile system). LLVM projects
> > that want to use this system should use its facilities and not > > override
> > them. If someone doesn't want to do that, then it shouldn't be > > regarded
> > as an LLVM project (in the makefile sense).
>
> However, projects should continue to be able to have their own configure
> scripts. It would be nice if this was optional though!

It already is optional. Projects don't even have to have a
Makefile.config. They just need a Makefile.common that all the sub
directories include and Makefile.common just needs to pick up llvm's
Makefile.config and Makefile.rules (via LLVM's Makefile.common).
The only reason we continue to have configured Makefile.config and
configure scripts is (a) because the project truly needs configurable
options or (b) that's just the way the project was before configuration
was made optional.

Is then installing mklib, install-sh, mkinstalldirs at LLVM install is acceptable.

I attempt modify LLVM makefile system and let LLVM projects used installed version of LLVM.

My plan:
1) add support installed LLVM version in Makefile.rules
(last patch version in http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003331.html
and some comments in http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003323.html )

2) shrink of files in LLVM projects using LLVM_(SRC|OBJ)_ROOT paths to only really requared
(this patch)

3) install files with LLVM install:
$(LLVM_SRC_ROOT)/Makefile.rules
$(LLVM_SRC_ROOT)/Makefile.common
$(LLVM_OBJ_ROOT)/Makefile.config
$(LLVM_OBJ_ROOT)/mklib
and (if current patch isn't acceptable)
$(LLVM_SRC_ROOT)/authoconf/install-sh
$(LLVM_SRC_ROOT)/authoconf/mkinstalldirs

4) copy $(LLVM_SRC_ROOT)/Makefile.rules to $(LLVM_OBJ_ROOT)/Makefile.rules at LLVM build
and set
LLVM_MAKE_ROOT to LLVM_ROOT or LLVM_OBJ_ROOT

5) add to llvm-java (and for consistency in Stacker and sample) configure.ac support --with-llvm option
as alternative to --with-llvmsrc/--with-llvmobj
and add to $(PROJ_SRC_ROOT)/Makefile.common.in code for seting LLVM_ROOT
and add to $(PROJ_SRC_ROOT) using LLVM_MAKE_ROOT instead LLVM_(SRC|OBJ)_ROOT paths.

At this point LLVM projects can build using installed LLVM version or only build LLVM version.

Vladimir

[Tanu_Sharma]

Hello,

In an attempt to randomise the basic blocks in a function, is it possible that I can randomise the entry block as well? And maybe insert some instructions in the pass to call entry block while running the program ?

Is it feasible?

What does entry block consist of ?

Thanks

Tanu

[John_Criswell1]

Tanu Sharma wrote:

Hello,

In an attempt to randomise the basic blocks in a function, is it possible that I can randomise the entry block as well? And maybe insert some instructions in the pass to call entry block while running the program ?

Is it feasible?

What does entry block consist of ?

The entry block, by definition, is the first basic block (BB) to be executed by a function. As I understand it, it has the additional restriction that it cannot be dominated by other basic blocks (i.e. no other BBs in the function can branch to it).

If your entry BB performs useful computations and you want to move it, you could create a new entry BB that does nothing but branch to the old entry BB. The old entry BB (now just a regular BB) can then be moved.

I'm assuming thus far that you're randomizing the basic block order at the LLVM level (i.e. take LLVM function, randomize order of BBs, and then codegen each BB in order). Another approach, as I see it, would be to change the code generator so that it codegens the BBs in a random order, instead of codegen'ing them in order.

The first approach, I think, is a lot easier.

Regards,

-- John T.

[Tanu_Sharma]

Thanks a lot for replying.

I have another query.

If branching to the entry block is not legal in llvm how should I be able to create a new entry block for any existing list?

I created a new block and inserted it into the present basic block list , but I get this error:

opt: BasicBlock.cpp:83: virtual llvm::BasicBlock::~BasicBlock(): Assertion `getParent() == 0 && “BasicBlock still linked into the program!”’ failed.

The program completes its task and i get this in the end.
I am unable to resolve this.

Thanks
Tanu

[clattner]

I created a new block and inserted it into the present basic block list , but I get this error:

opt: BasicBlock.cpp:83: virtual llvm::BasicBlock::~BasicBlock(): Assertion `getParent() == 0 && "BasicBlock still linked into the program!"' failed.

The program completes its task and i get this in the end. I am unable to resolve this.

The problem there is that you're trying to delete some basic block that is still embedded into a function. There are several ways to accomplish this:

BasicBlock *BB = ...

// Approach number 1, the easy way:
BB->eraseFromParent();

// Approach number 2, the more explicit way:
BB->getParent()->getInstList().erase(BB); // Remove from list & delete

// Approach number 3, remove from the list, then delete it explicitly:
BB->getParent()->getInstList().remove(BB); // Just remove from list
delete BB; // Delete block

I strongly suggest using approach #1, but I listed all of them so you can see the relation between remove and erase.

-Chris

[Misha_Brukman2]

Minor correction there: replace "getInstList()" with
"getBasicBlockList()". The former is only applicable to BasicBlocks,
the latter to Functions.

[clattner]

oops, right, thanks Misha!

-Chris

[Tanu_Sharma]

Thanks a lot for replying…but I am not doing any deleting or removing node …I am trying to insert a “new” entry node in an existing list.
In another reply I understood (also mentioned on the site) that no other block can branch to the entry block.

How do I achieve this ? Is it feasible?Let me know if there is any example.

Thanks again,
Tanu

[clattner]

Thanks a lot for replying...but I am not doing any deleting or removing node ...I am trying to insert a "new" entry node in an existing list.
In another reply I understood (also mentioned on the site) that no other block can branch to the entry block.

How do I achieve this ? Is it feasible?Let me know if there is any example.

Can you provide a stack trace for the failed assertion?

-Chris