Hi Neil,
On 01/07/15 17:08, Neil Roberts wrote:
If we wanted to avoid growing the size of exec_list to four pointers
instead of three, maybe we could store it in a union like below:
struct exec_list {
union {
struct {
struct exec_node head_sentinel;
struct exec_node *dummy_pointer_a;
};
struct {
struct exec_node *dummy_pointer_b;
struct exec_node tail_sentinel;
};
};
/* ... */
};
This is using anonymous structs and unions so that you wouldn't have to
otherwise modify the patch.
I actually had thought about this, but technically, you can only use unions for
type aliasing if you perform all accesses (that are not to the 'active' member)
through the union. All the list processing code that iterates through all the
nodes including the tail sentinel would *technically* still have an aliasing
problem, because it doesn't go through the exec_list structure at all (though
in practice, I don't think it would ever manifest in as an issue in the
compiled code).
Why must all accesses go through the union? Consider the case:
int someMethod(float *f, int *i) {
*f = 4.0; // LINE A
int a = *i; // LINE B
return a;
}
If I had some union 'u' with { float ff; int ii; } then I could call the above
method, even if it was in a different module, with:
someMethod(&u.ff, &u.ii).
Now, that would mean that the compiler would not be allowed to re-order LINE A
and LINE B. But as I said, someMethod might be in a different module, where the
compiler does not know that 'i' and 'f' point to members of the same union. In
that case it assumes that 'i' and 'f' don't alias. Compare that to:
int someMethod(union u *a, union u *b)
{
u->ff = 4.0;
int a = u->ii;
return a;
}
In this version, accesses are through the union, and the compiler knows that
they potentially alias.
[...]
It looks like this might also require removing the constructor for
exec_node because you can't have objects with constructors in a union
apparently. If the constructor is just a safety net anyway then maybe
this won't cause any trouble. I don't know.
I suspect it is just a safety net, but I'm not sure.
Also just to note, your patch doesn't apply with git-am. Have you
cut-and-paste the patch file into an email? It looks like something has
done some word wrapping which has corrupted it. Eg:
[...]
Yes, I pasted into Thunderbird. I didn't realise it was wrapping lines, sorry. I'll
re-post it once I figure out how to prevent the wrapping (setting up "git
send-email" has proved difficult, I don't know how to get it to accept my
self-signed SMTP server certificate).
Thanks,
Davin
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
