change makefile for a VEX benchmark to use in LLVM-to-VEX chain
 

Hi Everyone,

The thing I would like to do is changing a benchmark Makefile; to be precise "H264decoder", which is placed inside the VEX open-source compiler "apps" folder; in a way that I can reuse it in my so-far built automated scripts. My scripts gett the .c file as the input and enter it to a chain of LLVM-to-VEX compilation with optimization parameters.

The only difference between the (gsm.c) becnhmark (which I already did) and the new one is that h264decoder has lots of inter-nested source and header files in which practically there won't be an easy way to combine them into just one clean file ( I tried, you can see the the thread still opens after a month here :
So to wrap up the question, Does anyone can help me change this part of my scripts (which was for gsm.c- one file) and use the h264 makefile of VEX to do the same for h264 ?

my Scripts:

H264- VEX Makefile (Uses the VEX cc):
So the Gsm.c was run like this:

1- get the parameters
2- Compile with LLVM (with the mentioned -o levels)
3- get the transformed files
4- input and compile with VEX
5- ./RUN
6- get the log file

BUT, h264 has to be like this:

1- get the parameters
2- for each of the .c files (around 10-15 files)
{
- Compile with LLVM
- get the transformed file
- input and compile with VEX
}
3- ./RUN
4- get the log file


Appreciate your help ;)

Amir

First some general comments:
Can be replaced with
Putting the transformation and compilation in a loop should go something like this (untested):

Thanks ntubski for the reply.

I think the loop part seems fine but as I traced the error, the execution fails in the
phase, since h264 generates near 30 .c files, but here it supposed to be just one ( since it was for gsm.c), the .c files are :
I think we have to find a way to make them llvm_transformed_#[1,30] and change the long-long to long format, then use a new loop for LLVM-to-VEX.

Thanks,

Amir

Oh Sorry, I forgot to comment the first remaining line (mv opt/*.c opt/llvm_transformed.c) , you nicely included those loop in your codes before as I saw now ;)

I executed the iterations, these are the errors now:
Thanks for your time buddy ;)

Amir

It's hard to say much without seeing the actual C code, but I would guess that
is caused by unsigned long long --> unsigned long transformation.

I see ;)

Here I attached the .c file. (opt/llvm_transformed_annexb.c)

Thanks for your time my friend.

Amir

The line numbers in the error messages don't seem to match up to the file you attached. The error messages mention line 1987, but there are only 1938 lines in the file you attached.

Is the Vex a 16bit machine? It looks like the code assumes ints are 32bit.

Sorry man, the point is I think, i attached the wrong file. Since each iteration error's line is different from the other!!

so this is the new errors :
and attached please consider the corresponding .c file.

Thanks ;)

Amir

The line numbers are still a little off it seems.
Seems to match line 1581:
The constant I bolded needs 64 bits to represent, if unsigned long is only 32 bits then your ull --> ul sed transformation will break the code.


Then there's the errors, which appear to be complaining about the llvm_fcmp_*() functions, I can't see why.

I see, then what do you suggest to do in case of fixing this problem ?

Didn't we add in the loop to fix this ? I got confused :|

Best,

Amir

You had the sed transformation in your initial script, I don't know why...

I just took a look at the h264 MakeFile ( you can see in my first question above), there is a parameter names :

"DBG?= 0
### Generate 32 bit executable : 1=yes, 0=no"

Do you if I place the actual MakeFile of h264 inside our (HOW ?!) loop script and set this DBG =1 the problem will be solved ??

Best,

Amir

The comment goes with following code line, not the preceding:
The rest of the Makefile doesn't actually use M32 for anything, so I'm not sure what it's good for. Also it's unclear to me what happens when 32bit is no: do we get a 16bit or 64bit executable?

You never explained why you have the sed ull --> ul thing in the first place; did you try removing it?

As far as I know, we used this to change from unsigned long long to long format in case of inputting them into vex which has the 32bit input architecture, but I don't know why it is working with gsm.c but not with h264, the point is I am using the h264decoder which is placed inside the vex embedded benchmarks, so it should be a problem with my scripts because when I directly use the make command, the MakeFile use the cc of the vex and make it without any problem...

Amir

Maybe gsm.c didn't use long long constants so your sed command didn't do anything. In general, I don't think that command makes sense.

The Makefile is compiling completely different source files, ie the ones before the "C to C" transformation. Perhaps you need to tell C-opt-C.sh to use only 32bit constants (by changing opt.cfg)?