[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572418800
 
 
   Now, we could have new elegant and simpler automatic detection of LLVM 
target triple (thanks @tqchen 's good idea). @tqchen @zhiics could you help to 
review new code again?  Thanks!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364578922
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Cool!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364577848
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Sorry I forget to mention you cannot pass std string because that will be 
treated as null terminate c str. Pass a ByteArray instead 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364576391
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   After printing the length, inside the PackImportToLLVM, blob is 1044, but 
inside codegen.codegen_blob, the length of blob is 2.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] jwfromm commented on issue #4639: [Relay/Topi][Op] Conv1D

2020-01-08 Thread GitBox 
jwfromm commented on issue #4639: [Relay/Topi][Op] Conv1D
URL: https://github.com/apache/incubator-tvm/pull/4639#issuecomment-572411450
 
 
   @masahi, maybe you could take a look too.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364573509
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Sorry for missing your comment before. I find one strange thing of this. 
When I do this:
   ```
 std::string bin = SerializeModule(mod);  
 std::string header;
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   header.push_back(((nbytes >> (i * 8)) & 0xffUL));
 }
std::string blob = header + bin;
std::cout << "blob " << blob; // Could print content

 // Call codegen_blob to generate LLVM module
 std::string codegen_f_name = "codegen.codegen_blob";
 // the codegen function.
 const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
 CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
 runtime::Module m = (*codegen_f)(blob, system_lib, target);
 return m;
   ```
   Inside the  codegen.codegen_blob function, after accepting the blob string 
data. Can not print blob. Do I miss something?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364573509
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Sorry for missing your comment before. I find one strange thing of this. 
When I do this:
   ```
 std::string bin = SerializeModule(mod);  
 std::string header;
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   header.push_back(((nbytes >> (i * 8)) & 0xffUL));
 }
std::string blob = header + bin;
std::cout << "blob " << blob; // Could print content

 // Call codegen_blob to generate LLVM module
 std::string codegen_f_name = "codegen.codegen_blob";
 // the codegen function.
 const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
 CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
 runtime::Module m = (*codegen_f)(blob, system_lib, target);
 return m;
   ```
   Inside the  codegen.codegen_blob function, we can't accept the blob string 
data. Can not print blob. Do I miss something?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] jikechao commented on issue #4061: nvcc fatal : Value 'sm_75' is not defined for option 'gpu-architecture'

2020-01-08 Thread GitBox 
jikechao commented on issue #4061: nvcc fatal   : Value 'sm_75' is not defined 
for option 'gpu-architecture'
URL: https://github.com/apache/incubator-tvm/issues/4061#issuecomment-572407567
 
 
   Hi, I came cross this bug the same as you, can you share the solution? thanks


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364573509
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Sorry for missing your comment before. I find one strange thing of this. 
When I do this:
   ```
 std::string bin = SerializeModule(mod);  
 std::string header;
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   header.push_back(((nbytes >> (i * 8)) & 0xffUL));
 }
std::string blob = header + bin;
std::cout << "blob " << blob; // Could print content

 // Call codegen_blob to generate LLVM module
 std::string codegen_f_name = "codegen.codegen_blob";
 // the codegen function.
 const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
 CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
 runtime::Module m = (*codegen_f)(blob, system_lib, target);
 return m;
   ```
   Inside the  codegen.codegen_blob function, we can't accept the blob string 
data. Print the blob is empty. But if we use previous os << std::hex to get hex 
data, we could accept the data successfully. Do I miss something?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364573509
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Sorry for missing your comment before. I find one strange thing of this. 
When I do this:
   ```
 std::string bin = SerializeModule(mod);  
 std::string header;
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   header.push_back(((nbytes >> (i * 8)) & 0xffUL));
 }
std::string blob = header + bin;
std::cout << "blob " << blob; // Could print content

 // Call codegen_blob to generate LLVM module
 std::string codegen_f_name = "codegen.codegen_blob";
 // the codegen function.
 const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
 CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
 runtime::Module m = (*codegen_f)(blob, system_lib, target);
 return m;
   ```
   Inside the  codegen.codegen_blob function, we can accept the blob string 
data. Print the blob is empty. But if we use previous os << std::hex to get hex 
data, we could accept the data successfully. Do I miss something?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] masahi commented on issue #4659: [CONV3D] remove incorrect schedule for conv3d_ndhwc

2020-01-08 Thread GitBox 
masahi commented on issue #4659: [CONV3D] remove incorrect schedule for 
conv3d_ndhwc
URL: https://github.com/apache/incubator-tvm/pull/4659#issuecomment-572404021
 
 
   if you remove schedule_conv3d_ndhwc_cuda, what happens if 
schedule_conv3d_ndhwc was called on cuda target? You get an error?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] wweic commented on a change in pull request #4665: [REFACTOR] relay::Module Def -> TypeDef

2020-01-08 Thread GitBox 
wweic commented on a change in pull request #4665: [REFACTOR] relay::Module Def 
-> TypeDef
URL: https://github.com/apache/incubator-tvm/pull/4665#discussion_r364558231
 
 

 ##
 File path: include/tvm/relay/module.h
 ##
 @@ -104,18 +104,20 @@ class ModuleNode : public RelayNode {
* \param update Controls whether you can replace a definition in the
* environment.
*/
-  TVM_DLL void AddDef(const GlobalTypeVar& var, const TypeData& type, bool 
update = false);
+  TVM_DLL void AddTypeDef(const GlobalTypeVar& var, const TypeData& type, bool 
update = false);
 
   /*!
-   * \brief Add a type definition to the global environment.
-   * \param var The name of the global function.
+   * \brief Add a type-level definition to the global environment.
+   * \param var The var of the global type definition.
* \param type The ADT.
* \param update Controls whether you can replace a definition in the
* environment.
*
-   * It does not do type inference as AddDef does.
+   * It does not do kind checking as AddTypeDef does.
 
 Review comment:
   ```suggestion
  * It does not do type checking as AddTypeDef does.
   ```
   
   `kind` is [type of type](https://en.wikipedia.org/wiki/Kind_(type_theory)), 
here should be type checking instead.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572378913
 
 
   sounds good @FrozenGene  i agree with all your points


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572375077
 
 
   > > if cl is used, I think we can safely assume the target is windows, we 
only need to know whether if it is win32 or win64, i am not that familar with 
cl to know for sure, but i guess in that case we can pass and use LLVM module 
detection, or fallback to c
   > 
   > Yes. We could assume the target is Windows for sure. However, i think 
besides we need to know win32 / win64, one more thing I am a little worried. 
Windows could run ARM CPU (`cl.exe` could run Windows 10 on ARM? I can not make 
sure yet too).
   
   Ah...One tricky way I just see on the YoutuBe...
   
![image](https://user-images.githubusercontent.com/7287321/72037208-42026780-32d8-11ea-902a-5048249e4cfa.png)
   Maybe we could use `DUMPBIN` of `cl.exe` to make sure it is ARM or 
x86...But, it is so tricky, I personally think we maybe could fallback to c on 
Windows if we have fallen into `fcompile.get_target_triple()`. Because I think
   ```
   If the module lists already contains an LLVM module, we can get triples from 
those modules
   ```
   could solve most of our cases.
   
   How about your opinion? @tqchen


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572375077
 
 
   > > if cl is used, I think we can safely assume the target is windows, we 
only need to know whether if it is win32 or win64, i am not that familar with 
cl to know for sure, but i guess in that case we can pass and use LLVM module 
detection, or fallback to c
   > 
   > Yes. We could assume the target is Windows for sure. However, i think 
besides we need to know win32 / win64, one more thing I am a little worried. 
Windows could run ARM CPU (`cl.exe` could run Windows 10 on ARM? I can not make 
sure yet too).
   
   Ah...One tricky way I just see on the YoutuBe...
   
![image](https://user-images.githubusercontent.com/7287321/72037208-42026780-32d8-11ea-902a-5048249e4cfa.png)
   Maybe we could use `DUMPBIN` of `cl.exe` to make sure it is ARM or 
x86...But, it is so tricky, I personally think we maybe could fallback to c on 
Windows if we have fallen into `fcompile.get_target_triple()`. Because I think
   ```
   If the module lists already contains an LLVM module, we can get triples from 
those modules
   ```
   could solve most of our cases.
   
   How about your opinion?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572375077
 
 
   > > if cl is used, I think we can safely assume the target is windows, we 
only need to know whether if it is win32 or win64, i am not that familar with 
cl to know for sure, but i guess in that case we can pass and use LLVM module 
detection, or fallback to c
   > 
   > Yes. We could assume the target is Windows for sure. However, i think 
besides we need to know win32 / win64, one more thing I am a little worried. 
Windows could run ARM CPU (`cl.exe` could run Windows 10 on ARM? I can not make 
sure yet too).
   
   Ah...One tricky way I just see on the YoutuBe...
   
![image](https://user-images.githubusercontent.com/7287321/72037208-42026780-32d8-11ea-902a-5048249e4cfa.png)
   Maybe we could use `DUMPBIN` of `cl.exe` to make sure it is ARM or 
x86...But, it is so tricky, I personally think we maybe could fallback to c on 
Windows. Because I think
   ```
   If the module lists already contains an LLVM module, we can get triples from 
those modules
   ```
   could solve most of our cases.
   
   How about your opinion?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572373834
 
 
   > if cl is used, I think we can safely assume the target is windows, we only 
need to know whether if it is win32 or win64, i am not that familar with cl to 
know for sure, but i guess in that case we can pass and use LLVM module 
detection, or fallback to c
   
   Yes. We could assume the target is Windows for sure. However, i think 
besides we need to know win32 / win64, one more thing I am a little worried. 
Windows could run ARM CPU (`cl.exe` could run Windows 10 on ARM? I can not make 
sure yet too).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364550096
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   std::string header;
   for (size_t i = 0; i < sizeof(nbytes); ++i) {
   header.push_back(((nbytes >> (i * 8)) & 0xffUL));
   }
   then pass header + content


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572372688
 
 
   if cl is used, I think we can safely assume the target is windows, we only 
need to know whether if it is win32 or win64, i am not that familar with cl to 
know for sure, but i guess in that case we can pass and use LLVM module 
detection, or fallback to c


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364549582
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   This is only about the way to serialize the bytes in a fixed endian. We 
should be able to directly append it to binary string and put it in the 
beginning.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364549582
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   This is only  a way to serialize the nbytes in a fixed endian. We should be 
able to directly append it to binary string and put it in the beginning.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572361186
 
 
   > Some ideas about automatic detection, in the order of things that can be 
tried
   > 
   > * If the module lists already contains an LLVM module, we can get triples 
from those modules
   > * The property could be part of fcompile.get_target_triple()
   >   
   >   * Use hasattr to detect if fcompile contains the property
   >   * The function can return None, which means unable to detect
   >   * Note that for gcc and clang `gcc -dumpmachine` will give you the triple
   >   * Add support for this function in create_shared(using `gcc 
-dumpmachine`)
   > * If we cannot detect using the above approach,  fallback to PackToC, note 
that this is super unlikely
   
   Good idea. One quick question, how about Windows's compiler `cl`? The `cl` 
(https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-listed-by-category?view=vs-2019)
 seems doesn't have option to show arch information of its self.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] vinx13 commented on issue #4546: [CODEGEN] Support cuda tensorcore subbyte int data type in auto tensorcore

2020-01-08 Thread GitBox 
vinx13 commented on issue #4546: [CODEGEN] Support cuda tensorcore subbyte int 
data type in auto tensorcore
URL: https://github.com/apache/incubator-tvm/pull/4546#issuecomment-572343213
 
 
   @Orion34C Could you please rebase against master?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364523911
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364521862
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364520904
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364521897
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364522892
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364523550
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[GitHub] [incubator-tvm] jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
jwfromm commented on a change in pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664#discussion_r364521435
 
 

 ##
 File path: docs/dev/convert_layout.rst
 ##
 @@ -0,0 +1,192 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+..http://www.apache.org/licenses/LICENSE-2.0
+..  Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+===
+Convert Layout Pass
+===
+**Author**: `Animesh Jain `_
+
+*
+1. Background
+*
+
+Data layout format describes how the data is laid out in the memory. For 
example, Tensorflow framework default data layout for convolution operator is 
NHWC, i.e, the data is 4-dimensions and is laid out in row-major format with N 
being the first dimension and C being the last dimension. Data layout has a 
major role in model performance, significantly affecting spatial and temporal 
locality. For example, Intel x86 backend in TVM prefers layout as NCHWc where 
the C dimension is tiled in 2 dimensions to exploit data locality efficiently. 
Similarly, CUDA backend prefers the data layout to be in NCHW format.
+
+Essentially, TVM has to deal with data layouts throughout the compiler 
toolchain - Framework parsers, Relay layout transformations, and TOPI 
schedules. As we move towards third-party codegen integration, which might have 
their own data layout restrictions, handling layouts at all levels in TVM 
toolchain is going to become even more challenging. Therefore, we developed a 
new Relay pass - **ConvertLayout** -- to reduce some of the complications that 
arise due to layout handling.
+
+If you directly want to understand the usage of ConvertLayout Pass, directly 
jump to Section 4 - Usage.
+
+*
+2. Motivation
+*
+
+Lets look at a simple scenario to understand the complications that arise due 
to different layouts - Suppose we want to compile a Tensorflow NHWC graph for 
an ARM edge device. But, suppose we currently support only NCHW schedules in 
TOPI for ARM. So, there is a mismatch between framework layout and 
TOPI-supported layout. One way to deal with this mismatch is to insert layout 
transforms before each and after convolution, such that resulting convolution 
has NCHW input data layout and can use TOPI schedules. However, this can lead 
to performance degradation because of the presence of too many layout 
transforms.
+
+We encountered similar problems in other use cases as well
+
+- No way to run TFLite graphs on Nvidia GPUs. TOPI has NCHW-only schedules for 
GPUs.
+- Ever-complicating logic in AlterOpLayout for convolution to support 
different pairs of layout transformations.
+- Sub-optimal performance for TF graphs due to extra layout transforms.
+- Complication in third-party codegen integrations like TRT that prefers data 
layout to be in one format.
+
+To solve these problems, we introduced *ConvertLayout* pass that sets up the 
infrastructure to change the data layout of the whole graph with minimal number 
of data layout transforms. In ideal cases, we will have only 2 layout 
transforms, one at the start and one at the end. An example to show the 
transformation is below
+
+
+.. code-block:: python
+
+   # Original graph - 2 convolutions in NHWC format.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = nn.conv2d(%x, %weight1, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ %1 = nn.relu(%0);
+ %2 = nn.conv2d(%1, %weight2, padding=[1, 1], channels=32, 
kernel_size=[3, 3], data_layout="NHWC", kernel_layout="HWIO");
+ nn.relu(%2)
+   }
+
+   # After ConvertLayout - For data, there is a transform at the start and 
at the end.
+   # For weights, there are transforms to adapt to NCHW layout. These will 
be removed with FoldConstant pass.
+   fn (%x: Tensor[(1, 56, 56, 64), float32], %weight1: Tensor[(3, 3, 64, 
32), float32], %weight2: Tensor[(3, 3, 32, 32), float32]) {
+ %0 = layout_transform(%x, src_layout="NHWC", dst_layout="NCHW") /* 
ty=Tensor[(1, 64, 56, 56), float32] */;
+ %1 = layout_transform(%weight1, src_layout="HWIO",

[incubator-tvm] branch master updated (2077cd5 -> baae28b)

2020-01-08 Thread zhic 
This is an automated email from the ASF dual-hosted git repository.

zhic pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git.


from 2077cd5  [CI] Recover Windows Mac Build CI via Github Actions (#4662)
 add baae28b  [Autotvm] Use VM compile to extract autotvm tasks (#4328)

No new revisions were added by this update.

Summary of changes:
 docs/api/python/relay/backend.rst  |  3 +
 python/tvm/autotvm/task/relay_integration.py   | 35 +
 python/tvm/relay/backend/vm.py | 85 +-
 src/relay/backend/vm/compiler.cc   | 44 ++-
 src/relay/backend/vm/compiler.h| 17 ++---
 tests/python/relay/test_autotvm_task_extraction.py | 18 -
 tests/python/relay/test_vm.py  |  2 +-
 7 files changed, 140 insertions(+), 64 deletions(-)

[GitHub] [incubator-tvm] zhiics merged pull request #4328: [Autotvm] Use VM compile to extract autotvm tasks

2020-01-08 Thread GitBox 
zhiics merged pull request #4328: [Autotvm] Use VM compile to extract autotvm 
tasks
URL: https://github.com/apache/incubator-tvm/pull/4328
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on issue #4328: [Autotvm] Use VM compile to extract autotvm tasks

2020-01-08 Thread GitBox 
zhiics commented on issue #4328: [Autotvm] Use VM compile to extract autotvm 
tasks
URL: https://github.com/apache/incubator-tvm/pull/4328#issuecomment-572335208
 
 
   Thanks @icemelon9 @comaniac @wweic @tmoreau89 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] trevor-m commented on issue #4660: Unicode, Base64 errors using SaveJSON, LoadJSON on constants with aarch64 only (works on x86_64)

2020-01-08 Thread GitBox 
trevor-m commented on issue #4660: Unicode, Base64 errors using SaveJSON, 
LoadJSON on constants with aarch64 only (works on x86_64)
URL: https://github.com/apache/incubator-tvm/issues/4660#issuecomment-572332791
 
 
   Sure, I will investigate it further
   
   On Wed, Jan 8, 2020 at 3:49 PM Tianqi Chen  wrote:
   
   > can you dig a bit into it? I feel it might be the problem of py_str and
   > encoding issue
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[incubator-tvm] branch master updated (b873e03 -> 2077cd5)

2020-01-08 Thread tqchen 
This is an automated email from the ASF dual-hosted git repository.

tqchen pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git.


from b873e03  [CONV] Reduce data size of asymmetric padding testcase (#4658)
 add 2077cd5  [CI] Recover Windows Mac Build CI via Github Actions (#4662)

No new revisions were added by this update.

Summary of changes:
 .github/workflows/main.yml   | 73 
 include/tvm/runtime/module.h | 22 ++---
 src/runtime/module.cc|  3 +-
 3 files changed, 85 insertions(+), 13 deletions(-)
 create mode 100644 .github/workflows/main.yml

[GitHub] [incubator-tvm] tqchen merged pull request #4662: [CI] Recover Windows Mac Build CI via Github Actions

2020-01-08 Thread GitBox 
tqchen merged pull request #4662: [CI] Recover Windows Mac Build CI via Github 
Actions
URL: https://github.com/apache/incubator-tvm/pull/4662
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen opened a new pull request #4665: [REFACTOR] relay::Module Def -> TypeDef

2020-01-08 Thread GitBox 
tqchen opened a new pull request #4665: [REFACTOR] relay::Module Def -> TypeDef
URL: https://github.com/apache/incubator-tvm/pull/4665
 
 
   The term Def was not very clear about what is the object of interest(could 
be function def or type def).
   Changes the term to TypeDef to be more explicit.
   
   
   cc @jroesch @wweic 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] anijain2305 opened a new pull request #4664: [Docs] Convert Layout pass.

2020-01-08 Thread GitBox 
anijain2305 opened a new pull request #4664: [Docs] Convert Layout pass.
URL: https://github.com/apache/incubator-tvm/pull/4664
 
 
   @yzhliu @zhiics @tqchen @trevor-m 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] jwfromm opened a new pull request #4663: [Relay/Topi][Op] 1D Pooling

2020-01-08 Thread GitBox 
jwfromm opened a new pull request #4663: [Relay/Topi][Op] 1D Pooling
URL: https://github.com/apache/incubator-tvm/pull/4663
 
 
   This PR adds 1D MaxPooling and AvgPooling to topi, relay, and the onnx 
frontend. These new operators pair well with the 1D convolutions added in PR 
#4639 to enable fully 1D networks for sequence processing.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] jwfromm commented on issue #4663: [Relay/Topi][Op] 1D Pooling

2020-01-08 Thread GitBox 
jwfromm commented on issue #4663: [Relay/Topi][Op] 1D Pooling
URL: https://github.com/apache/incubator-tvm/pull/4663#issuecomment-572328927
 
 
   @srkreddy1238 @yongwww, can you take a look at this PR?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4660: Unicode, Base64 errors using SaveJSON, LoadJSON on constants with aarch64 only (works on x86_64)

2020-01-08 Thread GitBox 
tqchen commented on issue #4660: Unicode, Base64 errors using SaveJSON, 
LoadJSON on constants with aarch64 only (works on x86_64)
URL: https://github.com/apache/incubator-tvm/issues/4660#issuecomment-572313419
 
 
   can you dig a bit into it? I feel it might be the problem of py_str and 
encoding issue


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser

2020-01-08 Thread GitBox 
zhiics commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser
URL: https://github.com/apache/incubator-tvm/pull/4497#issuecomment-572302884
 
 
   @alexwong I see the GPU frontend column in CI executes more than 100mins for 
the tests (and it still runs). That may cause some problems. For example, it 
might be terminated as we have a time limit for it. Probably we don't want to 
test different variations of each network.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen opened a new pull request #4662: [CI] Recover Windows Mac Build CI via Github Actions

2020-01-08 Thread GitBox 
tqchen opened a new pull request #4662: [CI] Recover Windows Mac Build CI via 
Github Actions
URL: https://github.com/apache/incubator-tvm/pull/4662
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen closed pull request #4661: Fix windows build after the latest dso module change.

2020-01-08 Thread GitBox 
tqchen closed pull request #4661: Fix windows build after the latest dso module 
change.
URL: https://github.com/apache/incubator-tvm/pull/4661
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4643: [REFACTOR] Replace TensorObj and TensorValue with NDArray

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4643: [REFACTOR] Replace 
TensorObj and TensorValue with NDArray
URL: https://github.com/apache/incubator-tvm/pull/4643#discussion_r364474121
 
 

 ##
 File path: python/tvm/relay/backend/interpreter.py
 ##
 @@ -23,27 +23,13 @@
 from . import _backend
 from .. import _make, analysis, transform
 from .. import module
-from ... import register_func, nd
+from ... import nd
 from ..base import NodeBase, register_relay_node
 from ..expr import Tuple, RefCreate, Call, Constant, GlobalVar, Function, const
 from ..scope_builder import ScopeBuilder
-from . import _vm
-
-class Value(NodeBase):
-"""Base class of all values.
-"""
-@staticmethod
-@register_func("relay.from_scalar")
-def from_scalar(value, dtype=None):
-"""Convert a Python scalar to a Relay scalar."""
-return TensorValue(const(value, dtype).data)
-
-def to_vm(self):
-return _vm._ValueToVM(self)
-
 
 @register_relay_node
-class TupleValue(Value):
+class TupleValue(NodeBase):
 
 Review comment:
   I just added a commit to replace NodeBase with Object


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics closed issue #4646: [TEST][FLAKY] topi/tests/python/test_topi_depthwise_conv2d_back_weight.py

2020-01-08 Thread GitBox 
zhiics closed issue #4646: [TEST][FLAKY] 
topi/tests/python/test_topi_depthwise_conv2d_back_weight.py
URL: https://github.com/apache/incubator-tvm/issues/4646
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on issue #4646: [TEST][FLAKY] topi/tests/python/test_topi_depthwise_conv2d_back_weight.py

2020-01-08 Thread GitBox 
zhiics commented on issue #4646: [TEST][FLAKY] 
topi/tests/python/test_topi_depthwise_conv2d_back_weight.py
URL: https://github.com/apache/incubator-tvm/issues/4646#issuecomment-572275446
 
 
   Close by #4653 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen opened a new pull request #4661: Fix windows build after the latest dso module change.

2020-01-08 Thread GitBox 
tqchen opened a new pull request #4661: Fix windows build after the latest dso 
module change.
URL: https://github.com/apache/incubator-tvm/pull/4661
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572236081
 
 
   Some ideas about automatic detection, in the order of things that can be 
tried
   
   - If the module lists already contains an LLVM module, we can get triples 
from those modules
   - The property could be part of fcompile.get_target_triple()
- Use hasattr to detect if fcompile contains the property
- The function can return None, which means unable to detect
- Note that for gcc and clang ```gcc -dumpmachine``` will give you the 
triple
- Add support for this function in create_shared(using ```gcc 
-dumpmachine```)
   - If we cannot detect using the above approach,  fallback to PackToC, note 
that this is super unlikely
   
   
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572236081
 
 
   Some ideas about automatic detection, in the order of things that can be 
tried
   
   - If the module lists already contains an LLVM module, we can get triples 
from those modules
   - The property could be part of fcompile.get_target_triple(), if such attrs 
existed
- The function can return None, which means unable to detect
- Note that for gcc and clang ```gcc -dumpmachine``` will give you the 
triple
   - If we cannot detect using the above approach,  fallback to PackToC, note 
that this is super unlikely
   
   
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572232368
 
 
   Hmm, i meant to have someway to automatically discover the triple and pass 
around, let us think a bit more about it. For example, if there is already an 
LLVM module in the modules, then we can get that from that module. 
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-57539
 
 
   > If we indeed needs to pass target triple, perhaps the best way to do so is 
to pass that as an argument of PackImportToLLVM
   
   @tqchen  So, your opinion is let the users specify. The API will become this:
   
```
  def export_library(self,
  file_name,
  fcompile=None,
  llvm_target=None,
  **kwargs):
   if enabled("llvm"):
  path_obj = temp.relpath("devc.o")
  m = _PackImportsToLLVM(self, is_system_lib,  llvm_target)
   ```
   
   If users doesn't set `llvm_target`, we use the default value. (system target 
triple).
   
   if users want to compile into another os / another cpu, they have to do this:
   ```module.export_library(..., llvm_target="llvm -target 
aarch64-linux-gnu-none")``` now.
   
   Does it make sense to you?
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-57539
 
 
   > If we indeed needs to pass target triple, perhaps the best way to do so is 
to pass that as an argument of PackImportToLLVM
   
   So, your opinion is let the users specify. The API will become this:
   
```
  def export_library(self,
  file_name,
  fcompile=None,
  llvm_target=None,
  **kwargs):
   if enabled("llvm"):
  path_obj = temp.relpath("devc.o")
  m = _PackImportsToLLVM(self, is_system_lib,  llvm_target)
   ```
   
   If users doesn't set `llvm_target`, we use the default value. (system target 
triple).
   
   if users want to compile into another os / another cpu, they have to do this:
   ```module.export_library(..., llvm_target="llvm -target 
aarch64-linux-gnu-none")``` now.
   
   Does it make sense to you?
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] trevor-m opened a new issue #4660: Unicode errors using SaveJSON, Base64 errors using LoadJSON on aarch64 only (works on x86_64)

2020-01-08 Thread GitBox 
trevor-m opened a new issue #4660: Unicode errors using SaveJSON, Base64 errors 
using LoadJSON on aarch64 only (works on x86_64)
URL: https://github.com/apache/incubator-tvm/issues/4660
 
 
   The code snippet below gives the following error on aarch64 during the call 
to `save_json` (NVIDIA jetson xavier to be specific):
   ```
   Traceback (most recent call last):
   
 File "repro.py", line 35, in 
   json_str = save_json(mod['main'])
   
 File "/home/nvidia/trevor-tvm/python/tvm/api.py", line 171, in save_json
   return _api_internal._save_json(node)
   
 File "/home/nvidia/trevor-tvm/python/tvm/_ffi/_ctypes/function.py", line 
210, in __call__
   return RETURN_SWITCH[ret_tcode.value](ret_val)
   
 File "/home/nvidia/trevor-tvm/python/tvm/_ffi/_ctypes/types.py", line 95, 
in 
   TypeCode.STR: lambda x: py_str(x.v_str),
   
 File "/home/nvidia/trevor-tvm/python/tvm/_ffi/base.py", line 46, in 

   py_str = lambda x: x.decode('utf-8')
   
   UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 202643: 
invalid start byte
   ```
   I have also gotten the following error while deserializing using `LoadJSON`:
   ```
 [bt] (3) 
/home/nvidia/trevor-tvm/build/libtvm.so(tvm::LoadJSON(std::__cxx11::basic_string, std::allocator >)+0x190) [0x7fa7c2da10]
 [bt] (2) 
/home/nvidia/trevor-tvm/build/libtvm.so(tvm::runtime::NDArray::Load(dmlc::Stream*)+0x5d0)
 [0x7fa7c2ee68]
 [bt] (1) 
/home/nvidia/trevor-tvm/build/libtvm.so(tvm::common::Base64InStream::Read(void*,
 unsigned long)+0x44c) [0x7fa7c2f88c]
 [bt] (0) 
/home/nvidia/trevor-tvm/build/libtvm.so(dmlc::LogMessageFatal::~LogMessageFatal()+0x4c)
 [0x7fa78de57c]
 File "/home/nvidia/trevor-tvm/src/node/../common/base64.h", line 177
   TVMError: Check failed: temp_ch_ == EOF || isspace(temp_ch_): invalid base64 
format
   ```
   
   The same exact code works fine on  Intel x86_64. The error only happens when 
_bind_params is called. Commenting out the call to _bind_params allows 
everything to work fine, but I need to bind the params for my project.
   
   
   ```
   import numpy as np
   import tvm
   from tvm import relay
   from tvm.contrib import graph_runtime
   import mxnet
   from mxnet.gluon.model_zoo.vision import get_model
   from tvm.api import save_json, load_json
   
   input_shape = (1, 3, 224, 224)
   block = get_model('resnet18_v1', pretrained=True)
   mod, params = relay.frontend.from_mxnet(block, shape={'data': input_shape}, 
dtype='float32')
   
   def _bind_params(func, params):
 name_dict = {}
 for arg in func.params:
   name = arg.name_hint
   if name in name_dict:
 name_dict[name] = None
   else:
 name_dict[name] = arg
 bind_dict = {}
 for k, v in params.items():
   if k not in name_dict:
 continue
   arg = name_dict[k]
   if arg is None:
 raise ValueError("Multiple args in the function have name %s" % k)
   bind_dict[arg] = relay.expr.const(v)
 return relay.expr.bind(func, bind_dict)
   
   mod['main'] = _bind_params(mod['main'], params)
   
   json_str = save_json(mod)
   mod = load_json(json_str)
   
   with relay.build_config(opt_level=3):
 graph, lib, params = relay.build(mod, "cuda", params=params)
   mod = graph_runtime.create(graph, lib, ctx=tvm.gpu(0))
   mod.set_input(**params)
   i_data = np.random.uniform(0, 1, input_shape).astype('float32')
   for i in range(10):
 mod.run(data=i_data)
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] u99127 commented on a change in pull request #4629: [QNN] Channel wise quantization - Quantize & Requantize

2020-01-08 Thread GitBox 
u99127 commented on a change in pull request #4629: [QNN] Channel wise 
quantization - Quantize & Requantize
URL: https://github.com/apache/incubator-tvm/pull/4629#discussion_r364403117
 
 

 ##
 File path: include/tvm/relay/qnn/attrs.h
 ##
 @@ -33,10 +33,15 @@ namespace qnn {
 
 /*! \brief Attribute for requantize operator */
 struct RequantizeAttrs : public tvm::AttrsNode {
+  int axis;
   std::string rounding;
   DataType out_dtype;
 
   TVM_DECLARE_ATTRS(RequantizeAttrs, "relay.attrs.RequantizeAttrs") {
+TVM_ATTR_FIELD(axis)
+  .describe("The output channel axis for channel wise quantization. 
Default value is -1,"
+"which corresponds to the last axis.")
 
 Review comment:
   Never mind , later in the thread things are a bit clearer. The axis of -1 is 
fine - it is part of the per-channel quantization scheme . 
   
   In some sense I would have preferred to see a IsPerChannelQuantized 
predicate, rather than reusing a IsConstScalar predicate further below but 
that's a code hygiene thing.
   
   And , yes sorry about the slow response, I'm a bit snowed under.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572219346
 
 
   If we indeed needs to pass target triple, perhaps the best way to do so is 
to pass that as an argument of PackImportToLLVM


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] u99127 commented on a change in pull request #4629: [QNN] Channel wise quantization - Quantize & Requantize

2020-01-08 Thread GitBox 
u99127 commented on a change in pull request #4629: [QNN] Channel wise 
quantization - Quantize & Requantize
URL: https://github.com/apache/incubator-tvm/pull/4629#discussion_r364400908
 
 

 ##
 File path: include/tvm/relay/qnn/attrs.h
 ##
 @@ -33,10 +33,15 @@ namespace qnn {
 
 /*! \brief Attribute for requantize operator */
 struct RequantizeAttrs : public tvm::AttrsNode {
+  int axis;
   std::string rounding;
   DataType out_dtype;
 
   TVM_DECLARE_ATTRS(RequantizeAttrs, "relay.attrs.RequantizeAttrs") {
+TVM_ATTR_FIELD(axis)
+  .describe("The output channel axis for channel wise quantization. 
Default value is -1,"
+"which corresponds to the last axis.")
 
 Review comment:
   I don't have an opinion on whether this is the right approach or not but the 
question that popped in my mind was : 
   
   Why not be more explicit and say that axis == -1 actually means per-tensor 
quantization ?
   
   Thanks,
   Ramana


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] alexwong edited a comment on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser

2020-01-08 Thread GitBox 
alexwong edited a comment on issue #4497: [WIP] [Relay] Add a PyTorch to Relay 
Parser
URL: https://github.com/apache/incubator-tvm/pull/4497#issuecomment-572213105
 
 
   > @alexwong it seems CI is stuck after failing resnet test?
   
   Yes, also some operator unit tests failed (batch_norm and dense). Slightly 
hard to debug as I can't seem to reproduce locally atm. But I need to write 
some unit tests for handling different types and this may catch it. Will see 
what is happening.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364397872
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   I think we need this. The most important reason is we need this information:
   ```
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 
0xffUL);
 }
   ```
   Because when we load it back, we will do like this:
   ```
 uint64_t nbytes = 0;
 for (size_t i = 0; i < sizeof(nbytes); ++i) {
   uint64_t c = mblob[i];
   nbytes |=  (c & 0xffUL) << (i * 8);
 }
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] alexwong commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser

2020-01-08 Thread GitBox 
alexwong commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser
URL: https://github.com/apache/incubator-tvm/pull/4497#issuecomment-572213105
 
 
   > @alexwong it seems CI is stuck after failing resnet test?
   
   Yes, also some operator unit tests failed (batch_norm and dense). Slightly 
hard to debug as I can't seem to reproduce locally atm. Will see what is 
happening.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on a change in pull request #4657: [CodeGen] Generate blob 
use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364391776
 
 

 ##
 File path: python/tvm/build_module.py
 ##
 @@ -632,6 +632,10 @@ def build(inputs,
 if not target_host:
 target_host = "llvm" if module.enabled("llvm") else "stackvm"
 
+# set the target host based on llvm
 
 Review comment:
   See my follow comment of this, I think it should answer why we can not use 
```target.create("llvm")``` simply.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4643: [REFACTOR] Replace TensorObj and TensorValue with NDArray

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4643: [REFACTOR] Replace 
TensorObj and TensorValue with NDArray
URL: https://github.com/apache/incubator-tvm/pull/4643#discussion_r364382587
 
 

 ##
 File path: python/tvm/relay/backend/interpreter.py
 ##
 @@ -23,27 +23,13 @@
 from . import _backend
 from .. import _make, analysis, transform
 from .. import module
-from ... import register_func, nd
+from ... import nd
 from ..base import NodeBase, register_relay_node
 from ..expr import Tuple, RefCreate, Call, Constant, GlobalVar, Function, const
 from ..scope_builder import ScopeBuilder
-from . import _vm
-
-class Value(NodeBase):
-"""Base class of all values.
-"""
-@staticmethod
-@register_func("relay.from_scalar")
-def from_scalar(value, dtype=None):
-"""Convert a Python scalar to a Relay scalar."""
-return TensorValue(const(value, dtype).data)
-
-def to_vm(self):
-return _vm._ValueToVM(self)
-
 
 @register_relay_node
-class TupleValue(Value):
+class TupleValue(NodeBase):
 
 Review comment:
   Yes, I tried it, but it looked to me that we have to merge nodebase to 
object first before I can use object directly as there are fields not 
implemented in object, like getattr, etc. Should I use nodebase first then we 
can refactor them together?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4643: [REFACTOR] Replace TensorObj and TensorValue with NDArray

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4643: [REFACTOR] Replace 
TensorObj and TensorValue with NDArray
URL: https://github.com/apache/incubator-tvm/pull/4643#discussion_r364382587
 
 

 ##
 File path: python/tvm/relay/backend/interpreter.py
 ##
 @@ -23,27 +23,13 @@
 from . import _backend
 from .. import _make, analysis, transform
 from .. import module
-from ... import register_func, nd
+from ... import nd
 from ..base import NodeBase, register_relay_node
 from ..expr import Tuple, RefCreate, Call, Constant, GlobalVar, Function, const
 from ..scope_builder import ScopeBuilder
-from . import _vm
-
-class Value(NodeBase):
-"""Base class of all values.
-"""
-@staticmethod
-@register_func("relay.from_scalar")
-def from_scalar(value, dtype=None):
-"""Convert a Python scalar to a Relay scalar."""
-return TensorValue(const(value, dtype).data)
-
-def to_vm(self):
-return _vm._ValueToVM(self)
-
 
 @register_relay_node
-class TupleValue(Value):
+class TupleValue(NodeBase):
 
 Review comment:
   Yes, I tried it, but but looks to me that we have to merge nodebase to 
object first before I can use object directly as there are fields not 
implemented in object, like getattr, etc. Should I use nodebase first then we 
can refactor them together?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene edited a comment on issue #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-57213
 
 
   @tqchen @zhiics About the LLVM target part, I also think current way maybe 
is not good. I also think of it and cost my some time. So I want to discuss it 
too. 
   
   Firstly Let me describe why we need llvm target host. 
   
   When we use PackImportToLLVM, we will need to use LLVM to create LLVM 
module. 
   
   However, we must need one target machine, this is answered to @tqchen 's 
question. We can not create one generic target. Because we have platform's 
specific feature to handle. 
See:https://github.com/apache/incubator-tvm/blob/4f1772c0598ae708477f457a993f5be52fa71eb9/src/codegen/llvm/codegen_blob.cc#L107
 and 
https://github.com/apache/incubator-tvm/blob/4f1772c0598ae708477f457a993f5be52fa71eb9/src/codegen/llvm/codegen_blob.cc#L167.
 Another thing is if we leave the target is empty, i.e. no 
module->setTargetTriple(target_triple.str()); On llvm 6.0 of Mac will report 
problem : assert error Target-incompatible DataLayout.
   
   More import thing is we need to consider the target host is not x86 cpu. For 
example, target host is llvm -target aarch64, if we leave it empty and build it 
on x86 server, we will generate devc.o into x86 format, but in fact we want 
aarch64 of devc.o. So in the codegen_blob part, we should know the correct llvm 
target host to generate correct file.
   
   Current way is a little ugly I think too. Current way will create target 
host based on LLVM when we have detected target host finally (because tvm.build 
/ relay.build's api could leave `target_host` be None, we have some logic to 
handle this situation). One simple way of course is let users specific the 
target host of llvm representation, but I use this ugly way is just to detect 
it automatically and don't want to let users do. I also want to listen to your 
advices. Thanks in advance.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-57213
 
 
   @tqchen @zhiics About the LLVM target part, I also think current way maybe 
is not good. I also think of it and cost my some time. So I want to discuss it 
too. 
   
   Firstly Let me describe why we need llvm target host. 
   
   When we use PackImportToLLVM, we will need to use LLVM to create LLVM 
module. 
   
   However, we must need one target machine, this is answered to @tqchen 's 
question. We can not create one generic target. Because we have platform's 
specific feature to handle. 
See:https://github.com/apache/incubator-tvm/pull/4657/files#diff-f3a67dc7be877c1da11892f6a8e5ae80R107-R109
 and 
https://github.com/apache/incubator-tvm/pull/4657/files#diff-f3a67dc7be877c1da11892f6a8e5ae80R107-R109.
 Another thing is if we leave the target is empty, i.e. no 
module->setTargetTriple(target_triple.str()); On llvm 6.0 of Mac will report 
problem : assert error Target-incompatible DataLayout.
   
   More import thing is we need to consider the target host is not x86 cpu. For 
example, target host is llvm -target aarch64, if we leave it empty and build it 
on x86 server, we will generate devc.o into x86 format, but in fact we want 
aarch64 of devc.o. So in the codegen_blob part, we should know the correct llvm 
target host to generate correct file.
   
   Current way is a little ugly I think too. Current way will create target 
host based on LLVM when we have detected target host finally (because tvm.build 
/ relay.build's api could leave `target_host` be None, we have some logic to 
handle this situation). One simple way of course is let users specific the 
target host of llvm representation, but I use this ugly way is just to detect 
it automatically and don't want to let users do. I also want to listen to your 
advices. Thanks in advance.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] kevinthesun commented on a change in pull request #4656: fix topi.nn.global_pool layout="NHWC"

2020-01-08 Thread GitBox 
kevinthesun commented on a change in pull request #4656: fix 
topi.nn.global_pool layout="NHWC"
URL: https://github.com/apache/incubator-tvm/pull/4656#discussion_r364379927
 
 

 ##
 File path: topi/src/topi.cc
 ##
 @@ -527,7 +527,7 @@ TVM_REGISTER_GLOBAL("topi.nn.pool_grad")
 TVM_REGISTER_GLOBAL("topi.nn.global_pool")
 .set_body([](TVMArgs args, TVMRetValue *rv) {
   *rv = nn::global_pool(args[0],
-static_cast(static_cast(args[1])));
+
static_cast(static_cast(args[1])),args[2]);
 
 Review comment:
   Please add a test case for this.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4656: fix topi.nn.global_pool layout="NHWC"

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4656: fix topi.nn.global_pool 
layout="NHWC"
URL: https://github.com/apache/incubator-tvm/pull/4656#discussion_r364378931
 
 

 ##
 File path: topi/src/topi.cc
 ##
 @@ -527,7 +527,7 @@ TVM_REGISTER_GLOBAL("topi.nn.pool_grad")
 TVM_REGISTER_GLOBAL("topi.nn.global_pool")
 .set_body([](TVMArgs args, TVMRetValue *rv) {
   *rv = nn::global_pool(args[0],
-static_cast(static_cast(args[1])));
+
static_cast(static_cast(args[1])),args[2]);
 
 Review comment:
   style : space between , and args


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[incubator-tvm] branch master updated (f4c5f93 -> b873e03)

2020-01-08 Thread tqchen 
This is an automated email from the ASF dual-hosted git repository.

tqchen pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git.


from f4c5f93  [REFACTOR][IR] Add Node suffix to low-level IR nodes (#4649)
 add b873e03  [CONV] Reduce data size of asymmetric padding testcase (#4658)

No new revisions were added by this update.

Summary of changes:
 topi/tests/python/test_topi_conv2d_NCHWc.py| 29 +
 topi/tests/python/test_topi_conv2d_int8.py | 20 -
 topi/tests/python/test_topi_conv2d_nchw.py | 30 +-
 topi/tests/python/test_topi_conv2d_winograd.py | 20 -
 4 files changed, 50 insertions(+), 49 deletions(-)

[GitHub] [incubator-tvm] tqchen merged pull request #4658: [CONV] Reduce data size of asymmetric padding testcase

2020-01-08 Thread GitBox 
tqchen merged pull request #4658: [CONV] Reduce data size of asymmetric padding 
testcase
URL: https://github.com/apache/incubator-tvm/pull/4658
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] yzhliu commented on issue #4642: [Relay][Frontend][TFLite] Add parser support for logical operators

2020-01-08 Thread GitBox 
yzhliu commented on issue #4642: [Relay][Frontend][TFLite] Add parser support 
for logical operators
URL: https://github.com/apache/incubator-tvm/pull/4642#issuecomment-572193822
 
 
   could you address the failure test?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] yzhliu commented on a change in pull request #4459: [RUNTIME] Implement TVMDSOOp(TensorFlow custom op) for TVM runtime

2020-01-08 Thread GitBox 
yzhliu commented on a change in pull request #4459: [RUNTIME] Implement 
TVMDSOOp(TensorFlow custom op) for TVM runtime
URL: https://github.com/apache/incubator-tvm/pull/4459#discussion_r364373429
 
 

 ##
 File path: cmake/modules/contrib/TF_TVMDSOOP.cmake
 ##
 @@ -0,0 +1,48 @@
+
+if(NOT USE_TF_TVMDSOOP STREQUAL "OFF")
+
+  # If want build this directly comment out below lines.
+  # if ("${TVM_HOME}" STREQUAL "")
+  #   message(FATAL_ERROR "TVM_HOME is not defined")
+  # else()
+  #  message("Use TVM_HOME=\"${TVM_HOME}\"")
+  #endif()
+  # include_directories(${TVM_HOME}/include)
+  # include_directories(${TVM_HOME}/3rdparty/dlpack/include)
+  # include_directories(${TVM_HOME}/3rdparty/dmlc-core/include)
+  # set(TFTVM_LINK_FLAGS  -ltvm_runtime -L${TVM_HOME}/build)
 
 Review comment:
   what's these for?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364361636
 
 

 ##
 File path: include/tvm/codegen.h
 ##
 @@ -59,6 +59,21 @@ runtime::Module Build(const Array& funcs,
  * \return cstr The C string representation of the file.
  */
 std::string PackImportsToC(const runtime::Module& m, bool system_lib);
+
+/*!
+ * \brief Pack imported device library to a LLVM module.
+ *  Compile the LLVM module and link with the host library
+ *  will allow the DSO loader to automatically discover and import
+ *  the dependency from the shared library.
+ *
+ * \param m The host module with the imports.
+ * \param system_lib Whether expose as system library.
+ * \param target LLVM target
+ * \return runtime::Module The generated LLVM module.
+ */
+runtime::Module PackImportsToLLVM(const runtime::Module& m,
+  bool system_lib,
+  const std::string& target);
 
 Review comment:
   use `Target` here looks better than string


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364364907
 
 

 ##
 File path: src/codegen/build_module.cc
 ##
 @@ -882,6 +887,16 @@ TVM_REGISTER_GLOBAL("_GetCurrentTarget")
   *ret = Target::Current(allow_not_defined);
   });
 
+TVM_REGISTER_GLOBAL("_GetLLVMTargetHost")
+.set_body([](TVMArgs args, TVMRetValue* ret) {
+  *ret = Target::GetLLVMTargetHost();
+});
+
+TVM_REGISTER_GLOBAL("_SetLLVMTargetHost")
 
 Review comment:
   Yeah, I don't think this is necessary. I have some comments above, please 
see if they make sense. We know exactly where we need LLVM target so we can 
probably just directly use it, instead of using these wrappers which seem 
unsafe to me as well.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364363249
 
 

 ##
 File path: python/tvm/build_module.py
 ##
 @@ -632,6 +632,10 @@ def build(inputs,
 if not target_host:
 target_host = "llvm" if module.enabled("llvm") else "stackvm"
 
+# set the target host based on llvm
 
 Review comment:
   do we really need to set target here? can we just pass 
`target.create("llvm")` at line 145 of `module.py` when it is enabled? Then we 
can remove a lot of code that are rarely/never used at any other places.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364363748
 
 

 ##
 File path: python/tvm/module.py
 ##
 @@ -140,10 +140,16 @@ def export_library(self,
  module.get_function("__tvm_is_system_module")())
 
 if self.imported_modules:
-path_cc = temp.relpath("devc.cc")
-with open(path_cc, "w") as f:
-f.write(_PackImportsToC(self, is_system_lib))
-files.append(path_cc)
+if enabled("llvm"):
+path_obj = temp.relpath("devc.o")
+m = _PackImportsToLLVM(self, is_system_lib, 
str(_target.get_llvm_target_host()))
 
 Review comment:
   See my above comment as this is the only place we may need the getter


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364365522
 
 

 ##
 File path: src/codegen/llvm/codegen_blob.cc
 ##
 @@ -0,0 +1,215 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+/*!
+ * \file codegen_blob.cc
+ */
+#ifdef TVM_LLVM_VERSION
+#include 
+#include 
+#include 
+#include "codegen_blob.h"
+
 
 Review comment:
   no need this blank line


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364364002
 
 

 ##
 File path: src/codegen/build_module.cc
 ##
 @@ -219,7 +219,8 @@ std::string GetDeviceName(const std::string& target_str) {
 
   return "";
 }
-
+// Initialize static member of target host
+Target Target::llvm_target_host_;
 
 Review comment:
   I don't think we need this


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
zhiics commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364360657
 
 

 ##
 File path: include/tvm/build_module.h
 ##
 @@ -109,6 +109,23 @@ class Target : public ObjectRef {
*/
   TVM_DLL static tvm::Target Current(bool allow_not_defined = true);
 
+  /*!
+   * \brief Get the target host based on LLVM.
+   * \return The target host based on LLVM.
+   */
 
 Review comment:
   I am not sure, but it looks a little wired to me to have these in `Target`. 
Shouldn't we just use `Target::llvm()` directly? 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4643: [REFACTOR] Replace TensorObj and TensorValue with NDArray

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4643: [REFACTOR] Replace 
TensorObj and TensorValue with NDArray
URL: https://github.com/apache/incubator-tvm/pull/4643#discussion_r364363814
 
 

 ##
 File path: python/tvm/relay/backend/interpreter.py
 ##
 @@ -23,27 +23,13 @@
 from . import _backend
 from .. import _make, analysis, transform
 from .. import module
-from ... import register_func, nd
+from ... import nd
 from ..base import NodeBase, register_relay_node
 from ..expr import Tuple, RefCreate, Call, Constant, GlobalVar, Function, const
 from ..scope_builder import ScopeBuilder
-from . import _vm
-
-class Value(NodeBase):
-"""Base class of all values.
-"""
-@staticmethod
-@register_func("relay.from_scalar")
-def from_scalar(value, dtype=None):
-"""Convert a Python scalar to a Relay scalar."""
-return TensorValue(const(value, dtype).data)
-
-def to_vm(self):
-return _vm._ValueToVM(self)
-
 
 @register_relay_node
-class TupleValue(Value):
+class TupleValue(NodeBase):
 
 Review comment:
   Let us inherit from Object for now, and have a subsequent PR to cleanup the 
python side.
   
   Also seems we might be able to use Array(or ADT, see discussion here 
https://discuss.tvm.ai/t/discuss-runtime-array-containers-array-adt-string/4582)
 for this after @wweic 's PR lands 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4643: [REFACTOR] Replace TensorObj and TensorValue with NDArray

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4643: [REFACTOR] Replace 
TensorObj and TensorValue with NDArray
URL: https://github.com/apache/incubator-tvm/pull/4643#discussion_r364363086
 
 

 ##
 File path: python/tvm/relay/backend/interpreter.py
 ##
 @@ -23,27 +23,13 @@
 from . import _backend
 from .. import _make, analysis, transform
 from .. import module
-from ... import register_func, nd
+from ... import nd
 from ..base import NodeBase, register_relay_node
 from ..expr import Tuple, RefCreate, Call, Constant, GlobalVar, Function, const
 from ..scope_builder import ScopeBuilder
-from . import _vm
-
-class Value(NodeBase):
-"""Base class of all values.
-"""
-@staticmethod
-@register_func("relay.from_scalar")
-def from_scalar(value, dtype=None):
-"""Convert a Python scalar to a Relay scalar."""
-return TensorValue(const(value, dtype).data)
-
-def to_vm(self):
-return _vm._ValueToVM(self)
-
 
 @register_relay_node
-class TupleValue(Value):
+class TupleValue(NodeBase):
 
 Review comment:
   There is no Node anymore in the c++ side, see 
https://github.com/apache/incubator-tvm/pull/4603 and 
https://github.com/apache/incubator-tvm/issues/4647
   
   So NodeBase was a legacy item that we might need to upgrade on the python 
side.
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4654: convert onnx to tvm model error

2020-01-08 Thread GitBox 
tqchen commented on issue #4654: convert onnx to tvm model error
URL: https://github.com/apache/incubator-tvm/issues/4654#issuecomment-572181305
 
 
   Thanks for reporting the problem, the community uses https://discuss.tvm.ai/ 
as a way to collective resolve these questions. Please open a new 
troubleshooting thread there


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen closed issue #4654: convert onnx to tvm model error

2020-01-08 Thread GitBox 
tqchen closed issue #4654: convert onnx to tvm model error
URL: https://github.com/apache/incubator-tvm/issues/4654
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on issue #4655: convert keras model to tvm error

2020-01-08 Thread GitBox 
tqchen commented on issue #4655: convert keras model to tvm error
URL: https://github.com/apache/incubator-tvm/issues/4655#issuecomment-572181398
 
 
   Thanks for reporting the problem, the community uses https://discuss.tvm.ai/ 
as a way to collective resolve these questions. Please open a new 
troubleshooting thread there


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen closed issue #4655: convert keras model to tvm error

2020-01-08 Thread GitBox 
tqchen closed issue #4655: convert keras model to tvm error
URL: https://github.com/apache/incubator-tvm/issues/4655
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] trevor-m edited a comment on issue #4534: [Relay] Dead code elimination pass blows up call stack

2020-01-08 Thread GitBox 
trevor-m edited a comment on issue #4534: [Relay] Dead code elimination pass 
blows up call stack
URL: https://github.com/apache/incubator-tvm/issues/4534#issuecomment-571817854
 
 
   I was getting a segfault during `relay.build()` while trying to run 
resnet152_v1 with the script below. Smaller models worked fine. Once I 
increased my machine's stack limit using `ulimit -s unlimited`, the segfaults 
stopped. The stack limit was 8192 kilobytes originally. Might be related?
   
   ```
   import numpy as np
   import tvm
   from tvm import relay
   from tvm.contrib import graph_runtime
   import mxnet
   from mxnet.gluon.model_zoo.vision import get_model
   input_shape = (1, 3, 224, 224)
   block = get_model('resnet152_v1', pretrained=True)
   mod, params = relay.frontend.from_mxnet(block, shape={'data': input_shape}, 
dtype='float32')
   with relay.build_config(opt_level=3):
   graph, lib, params = relay.build(mod, "cuda", params=params)
   mod = graph_runtime.create(graph, lib, ctx=tvm.gpu(0))
   mod.set_input(**params)
   i_data = np.random.uniform(0, 1, input_shape).astype('float32')
   for i in range(10):
   mod.run(data=i_data)
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[incubator-tvm] branch master updated (df02e73 -> f4c5f93)

2020-01-08 Thread tqchen 
This is an automated email from the ASF dual-hosted git repository.

tqchen pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git.


from df02e73  reduce input size to fix oom (#4653)
 add f4c5f93  [REFACTOR][IR] Add Node suffix to low-level IR nodes (#4649)

No new revisions were added by this update.

Summary of changes:
 include/tvm/arithmetic.h|  12 +-
 include/tvm/attrs.h |  12 +-
 include/tvm/expr.h  |  22 +-
 include/tvm/expr_operator.h |  40 +--
 include/tvm/ir.h| 160 -
 include/tvm/ir_functor_ext.h| 360 ++---
 include/tvm/ir_pass.h   |   6 +-
 include/tvm/operation.h |  14 +-
 include/tvm/relay/type.h|   2 +-
 src/api/api_ir.cc   |  27 +-
 src/api/api_lang.cc |   4 +-
 src/arithmetic/analyzer.cc  |   8 +-
 src/arithmetic/bound_deducer.cc |  40 +--
 src/arithmetic/canonical_simplify.cc|  84 ++---
 src/arithmetic/compute_expr.h   |  14 +-
 src/arithmetic/const_fold.h | 132 
 src/arithmetic/const_int_bound.cc   |  42 +--
 src/arithmetic/detect_linear_equation.cc|  30 +-
 src/arithmetic/domain_touched.cc|  16 +-
 src/arithmetic/int_operator.h   |  32 +-
 src/arithmetic/int_set.cc   | 144 -
 src/arithmetic/ir_mutator_with_analyzer.cc  |  32 +-
 src/arithmetic/ir_mutator_with_analyzer.h   |  18 +-
 src/arithmetic/ir_visitor_with_analyzer.h   |   6 +-
 src/arithmetic/modular_set.cc   |  30 +-
 src/arithmetic/pattern_match.h  | 120 +++
 src/arithmetic/rewrite_simplify.cc  | 132 
 src/arithmetic/rewrite_simplify.h   |  46 +--
 src/arithmetic/stmt_simplify.cc |  12 +-
 src/autotvm/feature_visitor.cc  |  12 +-
 src/autotvm/feature_visitor.h   |   8 +-
 src/autotvm/touch_extractor.cc  |  41 +--
 src/autotvm/touch_extractor.h   |  10 +-
 src/codegen/build_module.cc |  44 +--
 src/codegen/codegen_c.cc| 138 
 src/codegen/codegen_c.h |  94 +++---
 src/codegen/codegen_c_host.cc   |  22 +-
 src/codegen/codegen_c_host.h|  10 +-
 src/codegen/codegen_cuda.cc |  42 +--
 src/codegen/codegen_cuda.h  |  30 +-
 src/codegen/codegen_metal.cc|  10 +-
 src/codegen/codegen_metal.h |  10 +-
 src/codegen/codegen_opencl.cc   |  18 +-
 src/codegen/codegen_opencl.h|  20 +-
 src/codegen/codegen_opengl.cc   |  22 +-
 src/codegen/codegen_opengl.h|  26 +-
 src/codegen/codegen_source_base.cc  |   4 +-
 src/codegen/codegen_source_base.h   |  10 +-
 src/codegen/codegen_vhls.cc |   4 +-
 src/codegen/codegen_vhls.h  |   8 +-
 src/codegen/intrin_rule.cc  |   8 +-
 src/codegen/intrin_rule.h   |   6 +-
 src/codegen/llvm/codegen_amdgpu.cc  |   8 +-
 src/codegen/llvm/codegen_arm.cc |  48 +--
 src/codegen/llvm/codegen_cpu.cc |  56 ++--
 src/codegen/llvm/codegen_cpu.h  |  18 +-
 src/codegen/llvm/codegen_llvm.cc| 134 
 src/codegen/llvm/codegen_llvm.h |  98 +++---
 src/codegen/llvm/codegen_nvptx.cc   |   6 +-
 src/codegen/llvm/codegen_x86_64.cc  |  23 +-
 src/codegen/llvm/intrin_rule_llvm.cc|  12 +-
 src/codegen/llvm/intrin_rule_llvm.h |  20 +-
 src/codegen/llvm/intrin_rule_nvptx.cc   |   6 +-
 src/codegen/llvm/intrin_rule_rocm.cc|   6 +-
 src/codegen/spirv/codegen_spirv.cc  | 114 +++
 src/codegen/spirv/codegen_spirv.h   |  80 ++---
 src/codegen/spirv/intrin_rule_spirv.cc  |   8 +-
 src/codegen/stackvm/codegen_stackvm.cc  | 108 +++
 src/codegen/stackvm/codegen_stackvm.h   |  80 ++---
 src/contrib/hybrid/codegen_hybrid.cc| 106 +++---
 src/contrib/hybrid/codegen_hybrid.h |  86 ++---
 src/lang/attr_functor.h | 204 ++--
 src/lang/attrs.cc   | 128 
 src/lang/buffer.cc  |  38 +--
 src/lang/data_layout.cc |  16 +-
 src/lang/expr.cc|  20 +-
 src/lang/expr_operator.cc   | 289 +

[GitHub] [incubator-tvm] tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on issue #4657: [CodeGen] Generate blob use LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#issuecomment-572161931
 
 
   cc @zhiics @yzhliu @ajtulloch  


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen merged pull request #4649: [REFACTOR][IR] Add Node suffix to low-level IR nodes

2020-01-08 Thread GitBox 
tqchen merged pull request #4649: [REFACTOR][IR] Add Node suffix to low-level 
IR nodes
URL: https://github.com/apache/incubator-tvm/pull/4649
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364338087
 
 

 ##
 File path: src/codegen/codegen.cc
 ##
 @@ -211,5 +220,30 @@ std::string PackImportsToC(const runtime::Module& mod, 
bool system_lib) {
  << "#endif\n";
   return os.str();
 }
+
+runtime::Module PackImportsToLLVM(const runtime::Module& mod,
+  bool system_lib,
+  const std::string& target) {
+  std::string bin = SerializeModule(mod);
+
+  std::ostringstream os;
+  uint64_t nbytes = bin.length();
+  os << std::hex;
+  for (size_t i = 0; i < sizeof(nbytes); ++i) {
+os << std::setfill('0') << std::setw(2) << ((nbytes >> (i * 8)) & 0xffUL);
+  }
+  for (size_t i = 0; i < bin.length(); ++i) {
+int c = bin[i];
+os << std::setfill('0') << std::setw(2) << (c & 0xff);
+  }
+
+  // Call codegen_blob to generate LLVM module
+  std::string codegen_f_name = "codegen.codegen_blob";
+  // the codegen function.
+  const PackedFunc* codegen_f = runtime::Registry::Get(codegen_f_name);
+  CHECK(codegen_f != nullptr)  << "codegen.codegen_blob is not presented.";
+  return (*codegen_f)(os.str(), system_lib, target);
 
 Review comment:
   Do we need to pass hex here? can we directly pass the binary blob to LLVM?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
tqchen commented on a change in pull request #4657: [CodeGen] Generate blob use 
LLVM directly
URL: https://github.com/apache/incubator-tvm/pull/4657#discussion_r364338819
 
 

 ##
 File path: src/codegen/build_module.cc
 ##
 @@ -882,6 +887,16 @@ TVM_REGISTER_GLOBAL("_GetCurrentTarget")
   *ret = Target::Current(allow_not_defined);
   });
 
+TVM_REGISTER_GLOBAL("_GetLLVMTargetHost")
+.set_body([](TVMArgs args, TVMRetValue* ret) {
+  *ret = Target::GetLLVMTargetHost();
+});
+
+TVM_REGISTER_GLOBAL("_SetLLVMTargetHost")
 
 Review comment:
   It is a bit bad to use global state to pass this argument around. Would be 
great to pass this argument as an argument of PackToLLVM instead.
   
   
   I wonder if it is necessary to set the target to be the specific target, or 
can we directly use a somewhat generic target (this means LLVM won't perform 
any target specific optimization which is fine here)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[incubator-tvm] branch master updated (bc0274d -> df02e73)

2020-01-08 Thread tqchen 
This is an automated email from the ASF dual-hosted git repository.

tqchen pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git.


from bc0274d  [COMMUNITY] @MarisaKirisame -> committer (#4645)
 add df02e73  reduce input size to fix oom (#4653)

No new revisions were added by this update.

Summary of changes:
 topi/tests/python/test_topi_conv2d_NCHWc.py | 2 +-
 topi/tests/python/test_topi_conv2d_int8.py  | 2 +-
 topi/tests/python/test_topi_conv2d_nchw.py  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

[GitHub] [incubator-tvm] tqchen merged pull request #4653: [Fix] reduce input size to fix oom

2020-01-08 Thread GitBox 
tqchen merged pull request #4653: [Fix] reduce input size to fix oom
URL: https://github.com/apache/incubator-tvm/pull/4653
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] yongfeng-nv commented on issue #4651: Tensor Expression Debug Display (TEDD)

2020-01-08 Thread GitBox 
yongfeng-nv commented on issue #4651: Tensor Expression Debug Display (TEDD)
URL: https://github.com/apache/incubator-tvm/pull/4651#issuecomment-572148284
 
 
   One question about test failure: 
https://ci.tvm.ai/blue/organizations/jenkins/tvm/detail/PR-4651/2/pipeline
   
   > E   ModuleNotFoundError: No module named 'graphviz'
   
   It fails, because tedd depends on graphviz, but tvmai/ci-cpu:v0.54 doesn't 
have it.
   How to fix this issue?  Let ci-cpu install graphviz as ci-gpu?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] yongfeng-nv commented on a change in pull request #4651: Tensor Expression Debug Display (TEDD)

2020-01-08 Thread GitBox 
yongfeng-nv commented on a change in pull request #4651: Tensor Expression 
Debug Display (TEDD)
URL: https://github.com/apache/incubator-tvm/pull/4651#discussion_r364318828
 
 

 ##
 File path: python/tvm/contrib/tedd.py
 ##
 @@ -0,0 +1,506 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""Tensor Expression Debug Display (TEDD), visualizing Tensor Expression"""
+import html
+from graphviz import Digraph
+from graphviz import Source
+from IPython.display import display
+from IPython.display import SVG
+import tvm
+
+TVMDD_TABLE_BODY_WIDTH = 30
+# Must match enum IterVarType defined in include/tvm/expr.h
+ITERVAR_TYPE_STRING_MAP = {
+0: ('kDataPar', '#FF'),
+1: ('kThreadIndex', '#2980B9'),
+2: ('kCommReduce', '#FAD7A0'),
+3: ('kOrdered', '#D35400'),
+4: ('kOpaque', '#ABB2B9'),
+5: ('kUnrolled', '#D2B4DE'),
+6: ('kVectorized', '#AED6F1'),
+7: ('kParallelized', '#F5B7B1'),
+8: ('kTensorized', '#A9DFBF'),
+}
+
+
+def get_or_create_dot_id(obj, prefix="", assert_on_missing=False):
+"""If obj's ID has been registered, return it.
+   If not, either assert or create a unique and legal ID, register and
+   return it, according to assert_on_missing.
+   ID must be a unique and legal Dotty ID.
+
+Parameters
+--
+obj : objet
+Serve as the key to the ID.
+
+prefix : string
+Prefix to attach to the ID.  Usually use obj's non-unique
+name as prefix.
+
+assert_on_missing : bool
+Asserts or not if object doesn't have a registered ID.
+"""
+prefix = prefix.replace('.', '_')
+if not hasattr(get_or_create_dot_id, "obj_id_dict"):
+get_or_create_dot_id.obj_id_dict = {}
+if obj not in get_or_create_dot_id.obj_id_dict:
+if assert_on_missing:
+assert False, 'dot_id ' + str(obj) + ' has not been registered.'
+else:
+get_or_create_dot_id.obj_id_dict[obj] = prefix + hex(id(obj))
+return get_or_create_dot_id.obj_id_dict[obj]
+
+
+def get_port_id(is_input, index):
+return 'I_' + str(index) if is_input else 'O_' + str(index)
+
+
+def get_itervar_type_info(iter_type):
+assert iter_type < len(
+ITERVAR_TYPE_STRING_MAP), 'Unknown IterVar type: ' + str(iter_type)
+return ITERVAR_TYPE_STRING_MAP[iter_type]
+
+
+def get_itervar_label_color(itervar, iv_type):
+type_info = get_itervar_type_info(iv_type)
+return str(itervar.var) + '(' + type_info[0] + ')', type_info[1]
+
+
+def linebrk(s, n):
+""" Break input string s with  for every n charactors."""
+result = ''
+j = 0
+for i, c in enumerate(s):
+if j == n and i != len(s) - 1:
+result = result + '\n'
+j = 0
+j = j + 1
+result = result + c
+result = html.escape(str(result), quote=True)
+result = result.replace('\n', '')
+return result
+
+
+def create_graph(name="", rankdir='BT'):
+graph = Digraph(name=name)
+graph.graph_attr['rankdir'] = rankdir
+return graph
+
+
+def itervar_label(itervar, index, index_color, label):
+return '' + str(
+index
+) + '' + label + ''
+
+
+def stage_label(stage):
+return stage.op.name + 'Scope: ' + stage.scope
+
+
+def legend_label():
+label = '<'
+for iter_type in ITERVAR_TYPE_STRING_MAP:
+name, color = ITERVAR_TYPE_STRING_MAP[iter_type]
+label += '' \
++ '' + name + ''
+label += '>'
+return label
+
+
+def legend_dot(g):
+with g.subgraph(name='cluster_legend') as subgraph:
+subgraph.attr(label='Legend')
+label = legend_label()
+subgraph.node('legend', label, shape='none', margin='0')
+
+
+def dump_graph(dot_string,
+   showsvg=True,
+   dotfilepath='',
+   outputdotstring=False):
+"""Output dot_string in various formats."""
+if dotfilepath:
+try:
+dot_file = open(dotfilepath, "w+")
+dot_file.write(dot_string)
+dot_file.close()
+except IOError:
+print('Cannot open file: ' + dotfilepath)
+if showsvg:
+src = Source(dot_string)
+

[GitHub] [incubator-tvm] mbarrett97 commented on a change in pull request #4543: [FRONTEND][TFLITE] Add support for TFLite_Detection_PostProcess

2020-01-08 Thread GitBox 
mbarrett97 commented on a change in pull request #4543: [FRONTEND][TFLITE] Add 
support for TFLite_Detection_PostProcess
URL: https://github.com/apache/incubator-tvm/pull/4543#discussion_r364290080
 
 

 ##
 File path: tests/python/frontend/tflite/test_forward.py
 ##
 @@ -1113,6 +1113,49 @@ def test_forward_fully_connected():
 _test_fully_connected([5, 1, 1, 150], [150, 100], [100])
 
 
+###
+# Custom Operators
+# ---
+
+def test_detection_postprocess():
+tf_model_file = tf_testing.get_workload_official(
+"http://download.tensorflow.org/models/object_detection/;
+"ssd_mobilenet_v2_quantized_300x300_coco_2019_01_03.tar.gz",
 
 Review comment:
   OK - I did see that model but weirdly it was as a .zip, not a tar as with 
most other hosted models. I'll see if I can open another PR to extend 
get_workload_official to zips and then will add the test.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] optima2005 opened a new pull request #4659: [CONV3D] remove incorrect schedule for conv3d_ndhwc

2020-01-08 Thread GitBox 
optima2005 opened a new pull request #4659: [CONV3D] remove incorrect schedule 
for conv3d_ndhwc
URL: https://github.com/apache/incubator-tvm/pull/4659
 
 
   This is a fix to #4604, to remove unnecessary and incorrect cuda schedule 
for conv3d_ndhwc
   
   @masahi  @icemelon9
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] optima2005 opened a new pull request #4658: [CONV] Reduce data size of asymmetric padding testcase

2020-01-08 Thread GitBox 
optima2005 opened a new pull request #4658: [CONV] Reduce data size of 
asymmetric padding testcase
URL: https://github.com/apache/incubator-tvm/pull/4658
 
 
   Further reduce the data size for asymmetric padding testcases #4653
   
   @tqchen  @yzhliu @zhiics


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] FrozenGene opened a new pull request #4657: [CodeGen] Generate blob use LLVM directly

2020-01-08 Thread GitBox 
FrozenGene opened a new pull request #4657: [CodeGen] Generate blob use LLVM 
directly
URL: https://github.com/apache/incubator-tvm/pull/4657
 
 
   This is one prior work of[ Module based Model Runtime Interface 
RFC](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025).
 In this RFC, we want to serialize params (weight) into shared library 
directly. 
   
   However, previous way of serializing the blob is to use `PackImportToC`, 
i.e. we will serialize the blob into char array `__tvm_dev_blob`, which stored 
the serialized result (0x...0x...), then we write this into `dev.cc` and pass 
to the compiler compiling. If we don't serialize params, it is ok. However, 
when we serialize params, the `__tvm_dev_blob` and `dev.cc` will become very 
large (resnet18 workload of `dev.cc` will be 380M, without serializing weight 
is 2.6M). The compiling time will increase very much (**Even 10x slower**). 
   
   According to the investigation, the bottleneck is the parsing time (see [GCC 
time 
report](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025/5?u=frozengene)).
   
   So we decide to avoid the C++ compiler (i.e. avoid the parsing time) and 
generate LLVM module directly. After testing, even we we serialize the params 
into shared library, the compiling time of generating blob is very fast. The 
compiling time of resnet18 on one cloud machine I tested before could **boost 
from 128.46s to 13.28s**. see[ previous 
test](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025/17?u=frozengene)
   
   After this work, I find it also have some a little improvement of compiling 
time compared previous way testing on my local machine (Intel i7-7700 CPU @ 
3.60GHz). 
   
   Workload is restnet18 on CUDA. Run 10 times and get the average
   
   | PackImportToC | PackImportToLLVM |
   | -| |
   | 8.586s | 8.082s  |
   
   @tqchen @zhiics @yzhliu @icemelon9 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] qihaitao opened a new pull request #4656: fix topi.nn.global_pool layout="NHWC"

2020-01-08 Thread GitBox 
qihaitao opened a new pull request #4656: fix topi.nn.global_pool layout="NHWC"
URL: https://github.com/apache/incubator-tvm/pull/4656
 
 
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-tvm] masahi commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser

2020-01-08 Thread GitBox 
masahi commented on issue #4497: [WIP] [Relay] Add a PyTorch to Relay Parser
URL: https://github.com/apache/incubator-tvm/pull/4497#issuecomment-571958569
 
 
   @alexwong it seems CI is stuck after failing resnet test?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

  1   2   >