Running the test-suite

Hello

I spent some time trying to get the test-suite running as per the instructions here: http://www.llvm.org/docs/TestingGuide.html

I was continually getting an error "No rule to make target `Output/sse.expandfft.linked.rbc', needed by `Output/sse.expandfft.linked.bc'."

Eventually, it turned out that calling configure without setting --with-llvmgccdir and having llvm-gcc in the path worked just fine. Can I suggest that the instruction docs are changed to reflect this?

Thanks

Hello

Hi Dominic!

I spent some time trying to get the test-suite running as per the
instructions here:http://www.llvm.org/docs/TestingGuide.html

Yep.

I was continually getting an error "No rule to make target
`Output/sse.expandfft.linked.rbc', needed by
`Output/sse.expandfft.linked.bc'."

Same for me, I grew some grey hair with this.

Eventually, it turned out that calling configure without setting
--with-llvmgccdir and having llvm-gcc in the path worked just fine. Can
I suggest that the instruction docs are changed to reflect this?

Since only some privileged people have CVS access, I could not do this
myself :frowning:

Sabre, can you *please* reflect this change, so that no more people
against this wall? :slight_smile:

Cheers,

    Gabor

I would like to make the following target specific modifications to
clang and would like to get some advice from experts.

1) My target supports very poor stack access so we implement "static
stack". In this model, all local variables will have static storage
class. I think I can take care of this in the
clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl()

2) To improve memory usage, I also would like to add a new default
attribute "overlay" to local variables (all will have static storage
class as mentioned in 1). This attribute will be applied to all local
variables except if the user has explicitly made the variable static in
which case the attribute is not added. I think I should be able to take
care of this also in the same place
clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl() however I don't
know how to define and apply the "overlay" attribute.

3) I did not find any way to access the attributes from llvm backend. I
was wondering if I should use something similar to what address space is
doing or there may be some other way possible.

4) Input arguments and return value of all functions should also have
the same overlay-static storage class. I can take care of these entirely
in the backend. However, I would like to know your feedback.

Thanks

I would like to make the following target specific modifications to
clang and would like to get some advice from experts.

Ok. cfe-dev might be more appropriate for clang questions, but...

1) My target supports very poor stack access so we implement "static
stack". In this model, all local variables will have static storage
class. I think I can take care of this in the
clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl()

Is there any reason not to lower these to alloca, and then have the code generator turn alloca into references to globals? That seems a more robust way to go.

2) To improve memory usage, I also would like to add a new default
attribute "overlay" to local variables (all will have static storage
class as mentioned in 1). This attribute will be applied to all local
variables except if the user has explicitly made the variable static in
which case the attribute is not added. I think I should be able to take
care of this also in the same place
clang::CGDecl.cpp::CodeGenFunction::EmitBlockVarDecl() however I don't
know how to define and apply the "overlay" attribute.

Ok. I'm not sure what this does, but adding attributes is pretty easy, just look at some other examples.

3) I did not find any way to access the attributes from llvm backend. I
was wondering if I should use something similar to what address space is
doing or there may be some other way possible.

I'd strongly recommend using address spaces if possible.

4) Input arguments and return value of all functions should also have
the same overlay-static storage class. I can take care of these entirely
in the backend. However, I would like to know your feedback.

I'm not sure what the question is :slight_smile:

-Chris

Chris,
The reasons for not wanting the code generator to modify alloca to
global references are:
(1) Variable name is not as easily available in the code generator.
(2) I did not want to go behind the back of compiler and change the
storage class of a variable in the middle of the way. I felt more
comfortable to have the frontend generate the correct information to
begin with.

But it concerns me when you say modifying alloca to global references
seems a more robust way of doing it. Could you elaborate on this?

Thanks
A.

Chris,
The reasons for not wanting the code generator to modify alloca to
global references are:
(1) Variable name is not as easily available in the code generator.
(2) I did not want to go behind the back of compiler and change the
storage class of a variable in the middle of the way. I felt more
comfortable to have the frontend generate the correct information to
begin with.

Ok, that is reasonable. You could also run an llvm IR pass that converts one to the other, which sound fix #1 at least. I agree that having the front-end emit the semantics that you want makes the most sense.

-Chris