Quantcast

Refactoring Clang's Target-specific ABI logic

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Refactoring Clang's Target-specific ABI logic

Ivan Garramona via cfe-dev
Hi everyone,

I'm looking to refactor Clang's ABI logic and I'm interested in
feedback about the approach.

The current situation seems to be that much of the ABI logic is inside
lib/CodeGen/TargetInfo.cpp and there is a class for each of the
targets ('WebAssemblyABIInfo', 'X86_32ABIInfo', 'X86_64ABIInfo',
etc.). I'm looking to move each of the classes out into their own
header/source files in a new lib/CodeGen/Target directory:

* lib/CodeGen/Target/WebAssemblyABIInfo.cpp
* lib/CodeGen/Target/X86_32ABIInfo.cpp
* lib/CodeGen/Target/X86_64ABIInfo.cpp
* etc.

To give you an idea of this, I've created a small patch[1] that moves
SwiftABIInfo into this new directory. I'm looking to apply these
changes incrementally (i.e. for each change move one or two classes
out), since this minimises conflicts with any work taking place on the
ABI logic.

To give some background, I have an LLVM frontend[2] that needs to
generate C ABI compliant LLVM IR. I created a library[3] that is a
fork of Clang's ABI logic, but now I'm looking to modify the library
to use Clang's logic directly, as recommended in a previous
discussion[4]. In general my goal is to simplify the ABI logic in both
LLVM and Clang and this seems like a good starting point.

What do you think?

Thanks,
Stephen

[1] https://reviews.llvm.org/D30164
[2] https://github.com/scrossuk/locic
[3] https://github.com/scrossuk/llvm-abi
[4] http://lists.llvm.org/pipermail/llvm-dev/2015-June/087252.html
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Refactoring Clang's Target-specific ABI logic

Ivan Garramona via cfe-dev
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.

On Mon, Feb 20, 2017 at 6:30 AM, Stephen Cross via cfe-dev <[hidden email]> wrote:
Hi everyone,

I'm looking to refactor Clang's ABI logic and I'm interested in
feedback about the approach.

The current situation seems to be that much of the ABI logic is inside
lib/CodeGen/TargetInfo.cpp and there is a class for each of the
targets ('WebAssemblyABIInfo', 'X86_32ABIInfo', 'X86_64ABIInfo',
etc.). I'm looking to move each of the classes out into their own
header/source files in a new lib/CodeGen/Target directory:

* lib/CodeGen/Target/WebAssemblyABIInfo.cpp
* lib/CodeGen/Target/X86_32ABIInfo.cpp
* lib/CodeGen/Target/X86_64ABIInfo.cpp
* etc.

To give you an idea of this, I've created a small patch[1] that moves
SwiftABIInfo into this new directory. I'm looking to apply these
changes incrementally (i.e. for each change move one or two classes
out), since this minimises conflicts with any work taking place on the
ABI logic.

To give some background, I have an LLVM frontend[2] that needs to
generate C ABI compliant LLVM IR. I created a library[3] that is a
fork of Clang's ABI logic, but now I'm looking to modify the library
to use Clang's logic directly, as recommended in a previous
discussion[4]. In general my goal is to simplify the ABI logic in both
LLVM and Clang and this seems like a good starting point.

What do you think?

Thanks,
Stephen

[1] https://reviews.llvm.org/D30164
[2] https://github.com/scrossuk/locic
[3] https://github.com/scrossuk/llvm-abi
[4] http://lists.llvm.org/pipermail/llvm-dev/2015-June/087252.html
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...