+ } fpvsr __attribute__((aligned(16)));
Do we really need a union here? what would happen if you just
changed
the type of fpr[32] from double to vector if #CONFIG_VSX?
I really dont like the union and think we can just make the storage
look opaque which is the key. I doubt we every really care about
using fpr[] as a double in the kernel.
I did something similar to this for the first cut of this patch, but
it
made the code accessing this structure much less readable.
really, what code is that?
Any code that has to read/write the top or bottom 64 bits _only_ of
the
128 bit vector.
The signals code is a good example where, for backwards compatibility,
we need to read/write the old 64 bit FP regs, from the 128 bit value
in
the struct.
Similarly, the way we've extended the signals interface for VSX, you
need to read/write out the bottom 64 bits (vsrlow) of a 128 bit value.
eg. the simple:
current->thread.fpvsr.fp[i].vsrlow = buf[i]
would turn into some abomination/macro.
it would turn into something like:
current->thread.fpr[i][2] = buf[i];
current->thread.fpr[i][3] = buf[i+1];
if you look at your code you'll see there are only a few places you
accessing the union as fpvsr.vsr[] and those places could easily be
fpr[], since they are already #CONFIG_VSX protected.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
