[LLVM] Register factory function for CodeGenCPU#11852
[LLVM] Register factory function for CodeGenCPU#11852leandron merged 3 commits intoapache:mainfrom kparzysz-quic:codegen-cpu-factory
Conversation
Any target that has its own subclass of `CodeGenLLVM` must register a factory function that constructs an object of that class. This factory will then be looked up and used in `CodeGenLLVM::Create`, which is the generic interface to create an LLVM code generator. However, there is no factory for `CodeGenCPU`, and so the creation of a `CodeGenCPU` object is done inside of `CodeGenLLVM::Create`. To make this happen, codegen_llvm.cc includes codegen_cpu.h, which makes the base class implementation depend on the derived class. This backwards dependency can be resolved by registering a factory for `CodeGenCPU`.
|
Thanks for the PR @kparzysz-quic. Is there any chance we can have a test case for this fix? |
|
I'm not sure what such a testcase should do. The main motivation for this change was to avoid the "reverse dependency" between .cc and .h files. The aren't any tests that I know of that are specific to the factory functions, but if you have any suggestions, let me know. |
Following the logic being introduced in this PR, I suppose tests could assert that two calls for the factory function will generate two different instances; another test could assert that an invalid target would return Does that make sense? |
|
Edit: the comment below is wrong.
Edit: the error message was |
leandron
left a comment
leandron
left a comment
There was a problem hiding this comment.
Thanks @kparzysz-quic! Merging it now.
* [LLVM] Register factory function for CodeGenCPU Any target that has its own subclass of `CodeGenLLVM` must register a factory function that constructs an object of that class. This factory will then be looked up and used in `CodeGenLLVM::Create`, which is the generic interface to create an LLVM code generator. However, there is no factory for `CodeGenCPU`, and so the creation of a `CodeGenCPU` object is done inside of `CodeGenLLVM::Create`. To make this happen, codegen_llvm.cc includes codegen_cpu.h, which makes the base class implementation depend on the derived class. This backwards dependency can be resolved by registering a factory for `CodeGenCPU`. * Add missing factory functions for other targets * Add cpp tests for codegen factories
* [LLVM] Register factory function for CodeGenCPU Any target that has its own subclass of `CodeGenLLVM` must register a factory function that constructs an object of that class. This factory will then be looked up and used in `CodeGenLLVM::Create`, which is the generic interface to create an LLVM code generator. However, there is no factory for `CodeGenCPU`, and so the creation of a `CodeGenCPU` object is done inside of `CodeGenLLVM::Create`. To make this happen, codegen_llvm.cc includes codegen_cpu.h, which makes the base class implementation depend on the derived class. This backwards dependency can be resolved by registering a factory for `CodeGenCPU`. * Add missing factory functions for other targets * Add cpp tests for codegen factories
2 participants
Any target that has its own subclass of
CodeGenLLVMmust register a factory function that constructs an object of that class. This factory will then be looked up and used inCodeGenLLVM::Create, which is the generic interface to create an LLVM code generator.However, there is no factory for
CodeGenCPU, and so the creation of aCodeGenCPUobject is done inside ofCodeGenLLVM::Create. To make this happen, codegen_llvm.cc includes codegen_cpu.h, which makes the base class implementation depend on the derived class. This backwards dependency can be resolved by registering a factory forCodeGenCPU.