On 26.11.2014 17:39, Gabriel wrote:
Thanks for the answer!
Sorry again for my unclear phrasing!
Just to be absolutely sure:
Lets say we have:
struct A{
Eigen::Vector2d t;
};
If we use A locally:
A a;
a.t
is a.t aligned on the Stack, (how does alignment work on the stack)
Yes, that is aligned on the stack. Also, if you wrote, e.g.
struct A{
char dummy; // compiler will add filling bytes after this
Eigen::Vector2d t;
};
a.t will be aligned on the stack.
The data member of Vector2d has a compiler attribute which tells it to
always have it aligned.
If we use A on the heap:
A * a = new A;
then as "a" is not aligned , also a.t is not aligned
It is not guaranteed to be aligned. It is, however, aligned on most
(all?) 64bit systems.
If we use EIGEN_MAKE_ALLOCATOR_NEW inside A , then "a" is aligned , and
Yes.
BUT what happens in this example:
struct B{
A a;
};
struct C{
B b;
};
std::vector< C , Eigen::aligned_allocator<C> > vec(1);
Is vec[0].b.a.t now aligned in memory? which does *NOT*
result in a segfault if Eigen uses SIMD internally?
Yes.
If we use locally lets say:
C c;
c.b.a.t do something with t
is c.b.a.t aligned on the Stack?
Yes.
Or on the heap:
C * c = new C;
c might not be aligned => c.b might not be aligned => c.b.a => might
not bealigned => c.b.a.t might not be aligned => SEGFAULT for usage of
c.b.a.t
Correct. c is not guaranteed to be aligned (except on most 64 bit
systems ...)
How do I need to correct the above example such that in the cases above,
vector A::t is always aligned to 16bytes?
To make the only not yet working case work, you need to add an
EIGEN_MAKE_ALIGNED_OPERATOR_NEW
into struct C. It would not hurt to add it into A and B, as well.
Christoph