Anyone is building a DSP-C frontend?

Project Infrastructure LLVM Dev List Archives
1

fixed-point number could be stored in LLVM first class integer types.
i cannot see the problem now. but to be type-safe, there should be a
first class 'fixed'.

some llvm extensions required to mapping dsp-c lanaguages could be
implemented as qualifiers.

1. _sat qualifier

Saturate the result within [0.0, +1.0> or [-1.0,+1.0> (unsigned/singed).

sat signed fixed a;
sat signed fixed b;
sat signed fixed c;
a = -0.75r; // 'r' is fixed-point number postfix
b = -0.75r;
c = a + b; /* c = -1.0r !!! */

this qualifier can be implemented just like the 'const' qualifier.

btw, in some implementation, the saturation is explicitly specifiedby
the arithmetic operation, not the variable itself. for example:

/* add the operands, saturate the result before it's assigned to c */
c = add_sat(-0.75, -0.75);

2. memory space qualifier

a typical program will have its global variables and constant in
different data segments. a segment is just a block with continuous
memory. there is no difference where the segment is. however, it's
different in the embedded system. usually constants are preferred to
be put in the ROM, while the global vars in SRAM. however, sometimes
the dsp programmer wants to explicitly specify where the data is. for
example, to put constant in RAM. for some strange reasons like cost
and access time.

int __rom x = 0; // const in ROM
int __ram y = 1; // const in RAM

2

fixed-point number could be stored in LLVM first class integer types.
i cannot see the problem now. but to be type-safe, there should be a
first class 'fixed'.

There is no need. Lowering is fine, in the same way that enums or typedefs are currently lowered to llvm integer types.

some llvm extensions required to mapping dsp-c lanaguages could be
implemented as qualifiers.

1. _sat qualifier

Saturate the result within [0.0, +1.0> or [-1.0,+1.0> (unsigned/singed).

sat signed fixed a;
sat signed fixed b;
sat signed fixed c;
a = -0.75r; // 'r' is fixed-point number postfix
b = -0.75r;
c = a + b; /* c = -1.0r !!! */

this qualifier can be implemented just like the 'const' qualifier.

This shouldn't be a type qualifier, if implemented in llvm, this should be new operations (e.g. add_sat). Saturating arithmetic would also be interesting for the vector/simd people.

btw, in some implementation, the saturation is explicitly specifiedby
the arithmetic operation, not the variable itself. for example:

/* add the operands, saturate the result before it's assigned to c */
c = add_sat(-0.75, -0.75);

The way it is expressed at the source language isn't important. However it is expressed there, it should be lowered to llvm operations that express what happens to the data (e.g. add_sat, sub_sat, etc).

2. memory space qualifier

a typical program will have its global variables and constant in
different data segments. a segment is just a block with continuous
memory. there is no difference where the segment is. however, it's
different in the embedded system. usually constants are preferred to
be put in the ROM, while the global vars in SRAM. however, sometimes
the dsp programmer wants to explicitly specify where the data is. for
example, to put constant in RAM. for some strange reasons like cost
and access time.

int __rom x = 0; // const in ROM
int __ram y = 1; // const in RAM

There are two pieces to this. Again, this shouldn't be a type qualifier. Instead it is an attribute on: globals, loads, and stores. An example of this is the volatile flag, which in C goes on the declaration but in llvm it goes on the access. Here you need to specify ram vs rom on the global itself presumably so the code generator knows where to emit the decl.

Adding these things to llvm is a very reasonable thing to do. If you're interested, it would probably be good to start with a basic code generator for a target that uses these things. Once the basic features are working, new extensions like these can natually be added to both the target and llvm itself.

-Chris

3

I have a doubt.

This is an excerpt of the raw report I get after running Spec benchmarks through llvm-test.I am trying to calculate the program execution time.Does the output result in bold corresponds to “lli time” in Makefile.spec ? I am not interested in llc, jit or cbe.I simply need the normal bytecode and native code execution times after running my pass over them.I have modified the Makefile for the same.

4

I have a doubt.

This is an excerpt of the raw report I get after running Spec benchmarks through llvm-test.I am trying to calculate the program execution time.Does the output result in bold corresponds to "lli time" in Makefile.spec ? I am not interested in llc, jit or cbe.I simply need the normal bytecode and native code execution times after running my pass over them.I have modified the Makefile for the same.

Which test are you using? I can't see bold (text only mailer), but the JIT time is the 'lli time'. If you don't care about LLC or CBE, you can pass "DISABLE_LLC=1 DISABLE_CBE=1" on the command line to disable them.

You should also be able to use reports to pull these raw files together into a table, as such, something like this might work for you:

  make TEST=nightly report DISABLE_LLC=1 DISABLE_CBE=1

You can also use the 'report.csv', 'report.html', or 'report.tex' targets if you're interested in importing the table into other tools.

-Chris

========= '/External/SPEC/CFP2000/177.mesa/177.mesa' Program

---------------------------------------------------------------

TEST-PASS: compile /External/SPEC/CFP2000/177.mesa/177.mesa

TEST-RESULT-compile: Total Execution Time: 45.1751 seconds (45.1877 wall clock)

TEST-RESULT-compile: 541814 Output/177.mesa.llvm.bc

TEST-RESULT-nat-time: program 2.870000

TEST-PASS: llc /External/SPEC/CFP2000/177.mesa/177.mesa

TEST-RESULT-llc: Total Execution Time: 12.9200 seconds (12.9080 wall clock)

TEST-RESULT-llc-time: program 5.040000

------------------------------------------------------------------

Thanks

Tanu

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-Chris

5

Thanks a lot for reply,

I am sorry but I am highly confused here.

In the Makefile, we have separate section for lli and jit ( lli pasted below).

Also, which value I am supposed to take if I am simple wanting to run my pass over the benckmark( as you can see in the test pasted below) and then simply get execution time of its bytecode and native code.

The report which we get has :
Total Execution Time in beginning, then JIT, CBE and LLC times.

This excerpt shows lli section and my changes.In this makefile I am trying to run my pass over the bytecode, convert the bytcode into native code such that I get the execution times for the native code.

LLI SECTION