[LLVMdev] A new mechanism to compiler kernel modules using llvm: Defer type evaluation in clang?

Jovi Zhang bookjovi at gmail.com
Mon Apr 29 08:30:44 PDT 2013


On Mon, Apr 29, 2013 at 10:38 PM, Joshua Cranmer <pidgeot18 at gmail.com> wrote:
> On 4/29/2013 9:13 AM, Jovi Zhang wrote:
>> We arrived the key part: offsetof and sizeof are resolved to a
>> constant by Clang before they are lowered to LLVM IR, so that's the
>> main reason why there have a high-level IR file except LLVM IR file,
>> that high-level IR file contain unresolved structure field reference
>> info and unresolved sizeof, that high-level IR file "link" with
>> kernel header ABI file which contain structure offset and sizeof
>> info, then generate to LLVM IR file, this is the design picture.
>>
>> I don't want to change LLVM IR format, I'm just thinking on hack
>> Clang to output that high-level IR file without resolved
>> offset/sizeof info, how about this sounds?
>
> I think that is much less feasible then it sounds. Since offsetof/sizeof are
> both compiled to a constant, they are both compile-time constants. In
> particular, you can do things in C like:
>
> #if sizeof(T) == 10
> ...
> #endif
Thanks Joshua, you comments is quite technical valuable.

I have to admit that putting sizeof into #if guard is a problem
against with my design,
but I think we can afford it, since there must have some workaround to
not write code like that in ko.
so if possible, code cannot compile if ko is writing code like that.

>
> This means that the only truly portable way to late-resolve offsetof/sizeof
> is to save the source code of the program and compile it as late as
> possible. I'm skeptical that you could convince all the stakeholders you
> would need to support this approach, especially since you are probably
> neither willing to implement any optimizations on your "high-level IR" nor
> able to make it close enough to LLVM IR to reuse LLVM's optimization
> passes--as a result, you would pretty much be distributing the source code
> to your driver module, just without the comments and less resilient to
> kernel changes than the original source.
>
Currently the idea is in design phase, so there may have many
possibility in final.

I hope the high-level IR file form is similar with LLVM IR, so it
would be simple to
link with kernel abi file, also I want it to be a IR form far from source code.
The main problem is structure offset/sizeof resolving.

I took many implementation design idea in mind, like use ffi library
in runtime, so it wouldn't be
engaging with compiler modification, but this cannot solve kernel
structure type fast reference problem.
I also thought about use some high-level language like Golang/Rust to
write kernel module,
then also have the type reference problem, and it will have problem if
those language have different
memory mode with C. writing kernel module in interpreter or JIT
statically typed language, like java,
but the performance will not accept by community.

So that's why I don't want to change the language of kernel module
currently, at least without big change
or limitation. LLVM meet my requirement mostly, mainly because it's
low level IR design,
LLVM is most near my solution at present :)  isn't it?



More information about the llvm-dev mailing list