[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]