use-diet design?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

use-diet design?

Gabor Greif
> Hi Gabor,
> Could you give a little more detailed description of the plan
> with the user-diet changes? I read the README but still don't
> have a good picture of what will happen.
> Specifically, which operators new/delete will be overridden?
> What work will they do? How will the surrogate getters/setters
> work?
> Thanks,
> Dan


Hi Dan,

I am going to summarize rapidly my previous correspondence with Chris.
(It is late here, so expect errors.)

We have 2 different layouts in the User (sub)classes:

Layout a)
The Use object(s) are inside of the User object and there are a fixed number of them.

Layout b)
The Use object(s) are referenced by a pointer to an array from the User object and
there may be a variable number of them.


Layout a) will be modelled by prepending the User object by the Use[] array.

...---.---.---.---.-------...
  | 0 | 0 | 2 | 1 | User
```---`---`---`---`-------```
    12  12  12  12

a bit-encoding in the 2 LSBits of the Use::Val will allow to find the
start of the User object:

00 --> binary digit 0 
01 --> binary digit 1 
10 --> stop and calc (s) 
11 --> full stop (S) 

Given a Use*, all we have to do is walk till we get a 
stop and we either have a User immediately behind or 
we have to walk to the next stop picking up digits 
and calculate the offset:

.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.----------------
| s | 1 | 0 | 1 | 1 | s | 0 | 1 | 1 | 0 | s | 0 | 0 | 0 | 1 | S | User (or User*)
'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'----------------
 +16                 +11                 +6                  +1
                                                            |___>
                                        |_______________________>
                    |___________________________________________>
|_______________________________________________________________>


For layout b) instead of the User we will find a pointer (with LSBit set).
Following this pointer brings us to the User.

For both layouts the location of the User can be calculated rapidly,
so there is no need to store Use::U in the Use object. This allows
us to shrink its size to 12 (from 16).

There are more middle-term savings, like eliminating the User::NumOperands member etc.

There will be placement 'operator new' and 'Create' static factories, that will
ensure that the layout invariants are met.

I hope this gives a bit of a background for discussion.

Cheers,

Gabor



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev