On 19/09/2017 05:49, Fulvio Risso wrote:
Dear Jiong, that's a great work.I havent' gone through the whole patches, but it seems to me that the documentation is not that much. From my past experiences, putting your hands into a compiler without at least some high-level documentation that presents how it works, it would be a nightmare.
Hi Fulvio,
Thanks for the feedback.
I agree that we need some high-level documentation on this. It could let
people evaluating the implementation approach taken and we could make sure
things on on correct direction.
I was dividing the 32-bit BPF support into the following three parts and
I am thinking the support of the first part could let the user be able to
construct testcases contaning 32-bit ALU which is good for experimenting
and it won't affect code-gen from .c/.ll. Aslo this part is not hard for
review and relatively independent, so I have seperated them out into this
patch set for review.
Detailed implementation details or high-level design will be included in
the cover letter of patch set for the second part which is the actually
part for 32-bit code-gen enablement.
brief intro on 32-bit BPF support phases
===
* Support in assembly level.
This includes cleanup of existing BPF instruction patterns to make them
32-bit support friendly and also the registration of 32-bit register set.
* Full code-gen Support in LLVM.
This includes making 32-bit integer type as legal type and associate it
with 32-bit register class, also we need to cleanup operation legalization
stragegies.
We need to discuss whether we want to make 32-bit BPF an new target or
just an new environment in LLVM's concept, so the user could simply enable
it through something like --triple=bpf-unknown-elf-ilp32. We may also need
new ELF attributes and new relocation types for map address relocation for
32-bit eBPF.
* Hook Clang driver with LLVM.
Support for this is straightforward, especially if we go with new environment
approach.
Regards,
Jiong
|