Re: [eigen] ABI break?

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

IMO, it is pretty clear we have to change the value of AutoAlign to 0.

About Dynamic, I would say that unless some users cannot tolerate such
an ABI break, I would change its value for a prime number and add a
limit anyway.

gael.

On Mon, Mar 23, 2009 at 6:18 AM, Patrick Mihelich
<patrick.mihelich@xxxxxxxxx> wrote:
> If you don't need ABI stability until 2.1, I say go ahead and make these
> sorts of mainly internal changes. Especially if it means fixing something
> nasty like the RowMajor bug.
>
> I don't have a strong opinion on the Dynamic issue either. Enforcing a hard
> limit on fixed sizes makes sense, otherwise you will have the occasional
> user who doesn't realize exactly what the difference is and blows out the
> stack.
>
> Patrick
>
> On Sat, Mar 21, 2009 at 9:55 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> at the moment there are 2 issues in Eigen 2.0 that can make us
>> considering breaking the ABI for 2.1
>>
>> First of all, since Eigen is pure template, it doesn't have an ABI by
>> itself. So what I am speaking of, is the ABI of binary libraries
>> exposing Eigen objects.
>>
>> In any case, we must not break the ABI after the 2.1 release (e.g.
>> libavogadro wants a stable ABI, and will make their 1.0 release soon).
>> The question is whether it's still OK to break the ABI between 2.0 and
>> 2.1.
>>
>> Here are the reasons why I'm considering breaking the ABI.
>>
>> 1) (the main reason). The "Options" template parameter to the Matrix
>> class is a bit-field, with one bit controlling RowMajor/ColMajor
>> storage, and another bit controlling automatic alignment. The default
>> is column-major and automatic alignment. We made a mistake in Eigen
>> 2.0: the value 0 corresponds to NO automatic alignment. This means
>> that if you want a RowMajor matrix and you pass just "RowMajor" as the
>> Options parameter, then you don't get automatic alignement ... you
>> have to pass RowMajor|AutoAlign if you want automatic alignment. What
>> this means is that people using row-major fixed-size vectorizable
>> matrices can be puzzled as to why they don't get vectorization. The
>> obvious solution is to set AutoAlign=0 and
>> DontAlign=the_corresponding_bit. However this means that in a binary
>> library, functions taking Matrix arguments will have a different
>> mangled name, so this change breaks the ABI.
>>
>> 2) See this bug report:
>>
>> http://forum.kde.org/strange-bug-for-large-fixed-sized-matrices-t-38426.html
>> Basically, a user had a fixed-size 100x100 matrix, so the size was
>> 10000, which gave him errors as 10000 is the value of our constant
>> Dynamic. So we have 2 options:
>> a) we can enforce a hard limit on fixed-sizes, e.g. size <= 4096;
>> b) or we can change the value of Dynamic.
>>
>> If we do b), that breaks the ABI, as Dynamic is often used as a
>> template parameter for the Matrix class template.
>>
>> We've already discussed possible values for Dynamic; the obvious
>> choice of -1 is dangerous as e.g. a condition like this,
>>
>>      SizeAtCompileTime <= 16
>>
>> would be satisfied by all dynamic-size matrices; whence our choice of
>> a large positive value; but then since we're often squaring this
>> value, in order to avoid integer overflow we don't want to go above
>> sqrt(MAX_INT) which is roughly 46000; also, we want a value that's
>> easily recognizable in backtraces and compiler output; finally, the
>> above bug report shows that this value shouldn't be a square (10000 =
>> 100^2) and more generally should be a prime number; so I propose
>> 33331.
>>
>> Well, there is always the option of finally setting Dynamic=-1 but
>> then we have to be extremely careful, not only at the time we make
>> this change, but ever after! Perhaps some helper macros would help
>> then.
>>
>> I don't have a strong opinion between a) and b) but again the big
>> drawback of b) is breaking the ABI.
>>
>> Cheers,
>> Benoit
>>
>>
>
>