Hi LLVM developers,
As one of the maintainers of AVR target, I want to update WritingAnLLVMBackend document to be familiar with the development of backend, because:
1. The structure of LLVMTargetMachine https://github.com/llvm-mirror/llvm/blob/master/docs/WritingAnLLVMBackend.rst#target-machine has been changed a lot!
2. LLVMInitializeSparcTargetInfo https://github.com/llvm-mirror/llvm/blob/master/docs/WritingAnLLVMBackend.rst#target-registration not mentioned the directory structure: TargetInfo/SparcTargetInfo.cpp
3. There is the Sparc target example in the document, but we could add AVR target as another example
Please give me some advice, thanks a lot!
Although contribution always welcome, personally I prefer making the
document as consistent as possible.
I don't know if it's a good idea interleaving different backend
Anyway, I think you can write a RFC (request for comment)
mail, describing what/where you feel unsatisfied
about current document, giving a draft to show us how you would improve the
document. I think that will make
the discussion more concrete.
I'm the maintainer for LLVM AVR backend wanted to update WritingAnLLVMBackend document. My apologies for the delay in responding.
I respect the document's original authors! Sorry for breaking consistent.
At the very beginning: SparcV8 skeleton https://github.com/llvm-mirror/llvm/commit/e785e531f4495068ee46cabd926939eec15a565a#diff-6998035da03f58a8c7e0ac3de7d21276
It was very close to the SPARC target example:
- similar constructor's variables
- similar get*Info methods
But the structure of backends and related components often be changed:
So doc might be out-of-date, but never mind, I can read the source code directly
å¨ 2017å¹´05æ03æ¥ 20:36, é³éä»» åé:
We all know the document is out-of-date once it has been written. My
thought is you can give
a general guild line, using existing backend as an example. Consistency is
that's why I think you can write up a draft document, explaining what you
want to improve, let
other has a solid base to give comment and feedback.
I believe that this is a necessary evil. I don’t think that we have a single back end that uses all of the target-agnostic codegen features, or hits all of the important corner cases of back-end development, and so a good document would necessarily cover multiple cases.
That said, I’m not sure that AVR is sufficiently different from SPARC that it makes a good example here.