[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Toon-members] General TooN aliasing problem
From: |
Edward Rosten |
Subject: |
Re: [Toon-members] General TooN aliasing problem |
Date: |
Thu, 28 Aug 2008 12:44:52 -0600 (MDT) |
On Wed, 27 Aug 2008, Ethan Eade wrote:
I've narrowed down the "bug" I had reported before to the test case below
(without TooN), which shows that it's actually an aliasing problem, and that
the compiler is entitled to get it "wrong".
The problem is with the use of reinterpret_cast<> to change data access
patterns (as in v.as_col() or m.T() or even matrix row access). The compiler
doesn't know that two different access patterns are referring to the same
memory, so the data dependencies aren't enforced, and the optimiser can put
reads before the necessary writes that generate the data.
Unfortunately, the compiler is not required to get these dependencies right.
Using reinterpret_cast<> is saying "give me no guarantees about data
dependencies". It was only a matter of time before the GCC optimiser got
aggressive enough to trigger the behaviour.
I don't see an easy fix for this; it requires a redesign of TooN internals if
optimisation is to be allowed.
I think it probably needs a redesign, though probably not a complete one.
In the past, castig one type to the other type was the only way to get
efficiency. These days, I expect you could pass back a proxy struct with a
pointer, and the optimizer would sort it all out.
-Ed