<div dir="ltr">Cool, people have been discussing this project for a while. I'd prefer not to nest this into CodeGen. It would probably fit better at top-level, since eventually it'd be nice for clients to only use this one part of clang. So, it would be lib/CGTarget, or lib/CGABI, or something like that.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 6:30 AM, Stephen Cross via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
I'm looking to refactor Clang's ABI logic and I'm interested in<br>
feedback about the approach.<br>
<br>
The current situation seems to be that much of the ABI logic is inside<br>
lib/CodeGen/TargetInfo.cpp and there is a class for each of the<br>
targets ('WebAssemblyABIInfo', 'X86_32ABIInfo', 'X86_64ABIInfo',<br>
etc.). I'm looking to move each of the classes out into their own<br>
header/source files in a new lib/CodeGen/Target directory:<br>
<br>
* lib/CodeGen/Target/<wbr>WebAssemblyABIInfo.cpp<br>
* lib/CodeGen/Target/X86_<wbr>32ABIInfo.cpp<br>
* lib/CodeGen/Target/X86_<wbr>64ABIInfo.cpp<br>
* etc.<br>
<br>
To give you an idea of this, I've created a small patch[1] that moves<br>
SwiftABIInfo into this new directory. I'm looking to apply these<br>
changes incrementally (i.e. for each change move one or two classes<br>
out), since this minimises conflicts with any work taking place on the<br>
ABI logic.<br>
<br>
To give some background, I have an LLVM frontend[2] that needs to<br>
generate C ABI compliant LLVM IR. I created a library[3] that is a<br>
fork of Clang's ABI logic, but now I'm looking to modify the library<br>
to use Clang's logic directly, as recommended in a previous<br>
discussion[4]. In general my goal is to simplify the ABI logic in both<br>
LLVM and Clang and this seems like a good starting point.<br>
<br>
What do you think?<br>
<br>
Thanks,<br>
Stephen<br>
<br>
[1] <a href="https://reviews.llvm.org/D30164" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D30164</a><br>
[2] <a href="https://github.com/scrossuk/locic" rel="noreferrer" target="_blank">https://github.com/scrossuk/<wbr>locic</a><br>
[3] <a href="https://github.com/scrossuk/llvm-abi" rel="noreferrer" target="_blank">https://github.com/scrossuk/<wbr>llvm-abi</a><br>
[4] <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-June/087252.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2015-June/<wbr>087252.html</a><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>