search for: concatenatoin

...ect reduction, DSP specific optimization, ... Therefore, we need some architectural information (both on-disk and in-memory) associated with the instructions after every synthesis pass. In addition, in hardware description, there are lots of bit-vector manipulations (e.g., bit extraction, concatenatoin ...), which are not represented in LLVM. We are thinking about to add some intrinsic functions to LLVM, so that the original instruction set can be untouched. Currently we use a simple CDFG (CFG, whose every node is a DFG) representation to do our synthesis. Of cource, it is not as powerful...

...opcodes). Once you want to do register allocation or want to add many low-level operations to the instruction set, then using the machine-level IR would be better. >   >    In addition, in hardware description, there are lots of bit-vector > manipulations (e.g., bit extraction, > concatenatoin ...), which are not represented in LLVM. We are > thinking about to add some intrinsic > functions to LLVM, so that the original instruction set can be > untouched. That makes sense if you don't want to apply standard LLVM passes (e.g., ADCE or LICM or PRE) to these operations....

Yiping, Could you describe in a little more detail what your goals are? I agree with Reid and Misha that modifying the instruction definition is usually not advisable but to suggest alternatives, we would need to know more. Also, for some projects it could make sense to change the instruction set. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Oct 20, 2004, at 2:41 PM,

On Wed, Oct 20, 2004 at 11:59:45AM -0700, Yiping Fan wrote: > Yeah. We need to have more extra fields in the instruction. Fo > example, during high-level synthesis, we must schedule an instruction > to a certain control step (or cycle), and bind it to be execute on a > certain functional unit, etc. Since we're talking about "execution" and "scheduling", you