From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-10-11 04:42:04
On 10/11/07, Steven Watanabe <steven_at_[hidden]> wrote:
> Simonson, Lucanus J <lucanus.j.simonson <at> intel.com> writes:
> > If the function call is inline the compiler knows whether the pointer is
> > the same or not and if it does not know it does not reorder the
> > instructions because it *might* be the same.
> What I'm saying is that compiler "knows" that the two pointers
> are not the same because if they are the same you have undefined
> behavior anyway so it's not non-conformant if it does something
Yes, this is very important! There is lots of code around that started
breaking when compilers started doing type based alias analysis
(practically all code that relied on undefined reinterpret casts
which were "practically safe"). Just because it works with current
compilers, It doesn't means it won't break with future ones when
they'll get smarter and smarter.
In the example shown by Steven, if b where declared static or in an
anonymous namespace I think that a compiler might reorder even if
'modify' is in another compilation unit if it can prove that the
address of b is never taken. And with current link time optimizations
technologies, not even an out of line function is a useful
> > In the back-end the
> > compiler doesn't have any idea what object type the pointer was anymore
> > and certainly doesn't use that information to outsmart itself. The
> > compiler is pessimistic and conservative in nature in the optimizations
> > it makes. If compiler providers chose to do what you suggest they might
> > then they would catch no end of grief until they rolled back the change.
That might have been true some years ago. Current compilers are pretty
aggressive when optimizing and will rely on every dark corner of the
specs as possible. And will do more so in the future.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk