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

On 4/29/2013 7:32 AM, Jovi Zhang wrote:
> The case I really want to solve is some kernel change cause ko must 
> need to recompile, like data structure field offset changed in new 
> kernel, this will make offset mismatch between new kernel and old ko. 
> This is the reason why I want to delay type structure evaluation into 
> install time in Clang, In theory, ko compiled now could work in 10 
> years later whatever how kernel changes. 
This kind of fix is not possible with LLVM IR right now and generally 
not possible with C code ever unless you make a lot of simplifying 
assumptions. Note that, for example, offsetof and sizeof are resolved to 
a constant by Clang before they are ever lowered to LLVM IR in the first 
place. Also, the way that structs are referenced in LLVM IR do not 
satisfy binary compatibility: a struct is lowered to a sequence of its 
constituent members accessed by their index and not be a given name. 
This means that inserting a member into the struct invalidates the IR.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On Mon, Apr 29, 2013 at 9:21 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com>
wrote:
> On 4/29/2013 7:32 AM, Jovi Zhang wrote:
>>
>> The case I really want to solve is some kernel change cause ko must
need
>> to recompile, like data structure field offset changed in new kernel,
this
>> will make offset mismatch between new kernel and old ko. This is the
reason
>> why I want to delay type structure evaluation into install time in
Clang, In
>> theory, ko compiled now could work in 10 years later whatever how
kernel
>> changes.
>
>
> This kind of fix is not possible with LLVM IR right now and generally not
> possible with C code ever unless you make a lot of simplifying assumptions.
> Note that, for example, offsetof and sizeof are resolved to a constant by
> Clang before they are ever lowered to LLVM IR in the first place. Also, the
> way that structs are referenced in LLVM IR do not satisfy binary
> compatibility: a struct is lowered to a sequence of its constituent members
> accessed by their index and not be a given name. This means that inserting
a
> member into the struct invalidates the IR.
>
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?

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

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.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/d008124d/attachment.html>