On Mon, Apr 27, 2009 at 6:21 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> You mean, besides the reasons already listed? Namely, no upstream changes
> are required, and I already have something that works.
>
> Sure, the same trick can be applied. But that requires a total backend
> rewrite plus dealing with linearize obstacles already described (ref
> linearize_load_gen, linearize_store_gen). Thus it is obviously a lot more
> work, with additional obstacles (patching upstream, which affects existing
> users), just get back to achieving the same result :)
I take a look at the how LLVM handle bit fields. Please correct me if
I am wrong.
LLVM does not take bit field member as a type. Given the example:
struct s {
int a:3;
int b:3;
} foo;
void func (struct s *a)
{
a->a = 6;
}
The LLVM outputs:
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
%struct.s = type <{ i8, [3 x i8] }>
@foo = common global %struct.s zeroinitializer, align 4 ;
<%struct.s*> [#uses=0]
define void @func(%struct.s* nocapture %a) nounwind {
entry:
%0 = getelementptr %struct.s* %a, i32 0, i32 0 ; <i8*> [#uses=2]
%1 = load i8* %0, align 1 ; <i8> [#uses=1]
%2 = or i8 %1, 6 ; <i8> [#uses=1]
%3 = and i8 %2, -2 ; <i8> [#uses=1]
store i8 %3, i8* %0, align 1
ret void
}
LLVM does not treat bit field as first class types. It apply bit mask
before/after
the load/store to fix things up. It actually is the same reason
linearize_load_gen
and linearize_store_gen exists in the first place. It does the same thing.
So the so call "obstacles" are actually what you need to handle bit
field correctly.
If you use linearized instruction in the first place, you would
already have bit field handle
correctly.
Let's review why you insist on duplicating the lineariztion effort.
1) You have the code already working.
True. But a back end base on linearize instruction will be much
simpler to your existing code. It does not make sense to have two
linearization implementation while they can share one.
2) Require up stream changes.
Let's compare apple to apple. Using linearize instruction to generate
a output exactly as your V2 does not require up stream changes.
It is not a reason to pick one over another.
3) Obstacles in linearize_load_gen and linearize_store_gen.
It turns out those "obstacles" are exactly what you need to handle
bit fields. One more reason to use linearize instructions.
4) More work to get the same results.
It will be more work for *you* to write yet another back end.
But if you compare the end result. The one base on linearize instruction
will be much simpler. It will be less new code get check in to the sparse
tree, less code for people other than you to review. Less work to maintain
one implementation of linearization instead of two.
Still not convinced using the linearization is a better way to go?
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
