The cgra-mapper from tancheng

Error occurs when test the "run.sh"

Hello! I am trying to using your tools to map same simple kernel to a cgra for my researh. I installed the llvm-11 from source code and use cmake-16 firstly, and then I compiled the cgra mapper successfully, but I met the following bug when I run the test script “run.sh” under the test folder:

terminate called after throwing an instance of 'nlohmann::detail::parse_error'
  what():  [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - unexpected end of input; expected '[', '{', or a literal
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.	Program arguments: opt -load ../../CGRA-Mapper/build/mapper/libmapperPass.so -mapperPass kernel.bc -f 
1.	Running pass 'Function Pass Manager' on module 'kernel.bc'.
2.	Running pass 'DFG Pass Analyse' on function '@main'
 #0 0x000055a173392b3e llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/opt+0x2c63b3e)
 #1 0x000055a173390914 llvm::sys::RunSignalHandlers() (/usr/local/bin/opt+0x2c61914)
 #2 0x000055a173390a58 SignalHandler(int) (/usr/local/bin/opt+0x2c61a58)
 #3 0x00007f896b1a13c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
 #4 0x00007f896ac7018b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
 #5 0x00007f896ac4f859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859)
 #6 0x00007f896b026911 (/lib/x86_64-linux-gnu/libstdc++.so.6+0x9e911)
 #7 0x00007f896b03238c (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa38c)
 #8 0x00007f896b0323f7 (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa3f7)
 #9 0x00007f896b0326a9 (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaa6a9)
#10 0x00007f896abf6bb0 bool nlohmann::detail::parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >, nlohmann::detail::input_stream_adapter>::sax_parse_internal<nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > > > >(nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > > >*) (../../CGRA-Mapper/build/mapper/libmapperPass.so+0x1cbb0)
#11 0x00007f896abf1475 nlohmann::detail::parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >, nlohmann::detail::input_stream_adapter>::parse(bool, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >&) (../../CGRA-Mapper/build/mapper/libmapperPass.so+0x17475)
#12 0x00007f896abeff5c nlohmann::operator>>(std::istream&, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >&) (../../CGRA-Mapper/build/mapper/libmapperPass.so+0x15f5c)
#13 0x00007f896abee032 (anonymous namespace)::mapperPass::runOnFunction(llvm::Function&) (../../CGRA-Mapper/build/mapper/libmapperPass.so+0x14032)
#14 0x000055a172b4736c llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/bin/opt+0x241836c)
#15 0x000055a172b47a39 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/bin/opt+0x2418a39)
#16 0x000055a172b46527 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/bin/opt+0x2417527)
#17 0x000055a170ece7b5 main (/usr/local/bin/opt+0x79f7b5)
#18 0x00007f896ac510b3 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b3)
#19 0x000055a170f6b3fe _start (/usr/local/bin/opt+0x83c3fe)
./run.sh: line 1:  8646 Aborted                 (core dumped) opt -load ../../CGRA-Mapper/build/mapper/libmapperPass.so -mapperPass kernel.bc -f

I lack the experience of developing a llvm pass so I donnot know how to solve it. Is it result from my using a cmake-1.6 rather than the required cmake1.0 or something else?

Heuristic mapper produce worst result when size of CGRA increase

I am trying to map the following kernel.

#include <string.h>
#include <stdio.h>


#define SIZE  20
int A[SIZE], B[SIZE], C[SIZE];

void external_fun() {C[0] = 7;}

__attribute__((noinline))
void array_cond(){

   int x;
   for (int i=0;i<SIZE; i++){
	if (A[i] > B[i]){
		C[i] = A[i] - B[i];
		if (C[i] < 0)
			C[i] = 0;
		else
			C[i] = A[i] * B[i];
	}
	else{
		C[i] = A[i] + B[i];
		if (C[i] > 10)
			C[i] = 10;
		else
			C[i] = A[i] - B[i];
	}
   }
}

int main(){

int i,j;

for (i=0;i<SIZE; i++){
      A[i] = i * 2 + 5;
      B[i] = i * 3 + 8;
      C[i] = 0;
    }
    
array_cond();

for (i=0;i<SIZE; i++) printf("%d\n", C[i]);
    
return 0;

}

When the CGRA size is 4x4 the mapper produces a mapping with II=13. When the size is 8x8, the mapped II=19.

This is the configuration used

{
  "kernel"                : "array_cond",
  "targetFunction"        : false,
  "targetNested"          : false,
  "targetLoopsID"         : [0],
  "doCGRAMapping"         : true,
  "row"                   : 8,
  "column"                : 8,
  "precisionAware"        : false,
  "heterogeneity"         : false,
  "isTrimmedDemo"         : true,
  "heuristicMapping"      : true,
  "parameterizableCGRA"   : false,
  "diagonalVectorization" : false,
  "bypassConstraint"      : 4,
  "isStaticElasticCGRA"   : false,
  "ctrlMemConstraint"     : 10,
  "regConstraint"         : 8,
  "optLatency"            : {
                              "load" : 2,
                              "store": 2
                            },
  "optPipelined"          : ["load", "store"],
  "additionalFunc"        : {
                              "load" : [],
                              "store": []
                            }
}

Should

TODO list

Successor in DFG should be outport dependent.
Current 'phi' assumes single predecessor, need check true/false for connection.
Should connect 'br' with all 'store' in DFG?
Need to check data dependency in array?

Parameters in param.json for mapping

Hello,
I am using the CGRA-Mapper combined with the param.json as a template as it can be found in the CGRA-Bench repository. But it seems like there are no real explanations given as to what each of the parameters is changing. I looked through the provided code here, but there also seem to be no comments. Could you please provide some descriptions to the parameters as, for example, the ones here: https://github.com/tancheng/CGRA-Bench/blob/master/kernels/gemm/param.json

Thank you very much in advance,
Stephan

Leverage protobuff or LLVM tabgen for codegen

And leverage existing open-source serializer and deserializer.

How can I get Mrrg?

Hi ,cheng
Where can I generate or obtain the MRRG of CGRA?
Thank you!
Have a nice Day!

TODO

Support nested loop

Two issues here

Outer loop's control (i.e., branch) no need to reach inner loop's basic block
Overall II can be decreased with HW supported fusion

Refactor mapper

Refactoring the mapper

Data struct: avoid using pointers
Provide simple kernel tests
DFG FL simulation as golden reference
Make it possible to plugin other mapping algorithm, say, LISA
Carefully model the registers in tile

How to use isStaticElasticCGRA feature

Hello,
Thanks for your public CGRA mapper repository.
I am trying to use your git repo for elastic CGRA (isStaticElasticCGRA parameter=true).
Is static-elastic-CGRA feature still supported with the latest commit? I see that your HPCA version works for a simple kernel, but the same kernel does not get mapped successfully with the latest branch.

I have a few naive questions, if you would be kind enough to shed some light on.

Should the CGRA size be larger than (or equal to) the number-of-instructions in DFG for static-elastic-mapper?
What is necessary for the default mapper (isStaticElasticCGRA=false) to have "elastic" loads/stores?

Thank you,
Sam

Limited support for PHI node

Currently, we can only support PHI nodes that are accompanied by CMP nodes (i.e., a problem caused by the implementation of phi node in the functional unit architecture). I might provide a new design of the PHI node in DFG in the future.
For now, it is better to manually change the following code:

  for(int x=0; x<total; ++x) {
    int i = x / maxNodeCount;
    int j = x % maxNodeCount;
    if(matrix[i][j] != 0) {
      value[index] = matrix[i][j];
      row[index] = i;
      col[index] = j;
      index++;
    }
  }

to:

  for(int x=0; x<total; ++x) {
    int i = x / maxNodeCount;
    int j = x % maxNodeCount;
    value[index] = matrix[i][j];
    row[index] = i;
    col[index] = j;
    if(matrix[i][j] != 0) {
      index++;
    }
  }

Should Phi op node be regraded as a control flow?

According to the OpenCGRA's papper,the mappers takes the iterative modulo algorithm for mapping. The dfg nodes should aligned in an topological order, however edges out from Phi nodes contruct a Recurrence Loop, which makes sorting topological order impossible since the whole graph doesn't belong to a DAG. I would appreciate it very much if you can reply !

tancheng / cgra-mapper Goto Github PK

cgra-mapper's People

Contributors

Stargazers

Watchers

Forkers

cgra-mapper's Issues

Recommend Projects

Recommend Topics

Recommend Org