Re: behavior-preserving optimization in C, was compiler bugs

"Christopher Glaeser" <cdg@nullstone.com>
Tue, 12 May 2009 10:46:22 -0700

          From comp.compilers

Related articles
[3 earlier articles]
Re: compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-04)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-05)
Re: compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-06)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-06)
Re: compiler bugs cfc@shell01.TheWorld.com (Chris F Clark) (2009-05-07)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-10)
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-12)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-13)
Re: behavior-preserving optimization in C, was compiler bugs dnovillo@acm.org (Diego Novillo) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs mcintosh@cup.hp.com (Nathaniel McIntosh) (2009-05-16)
Re: behavior-preserving optimization in C, was compiler bugs pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-18)
[18 later articles]
| List of all articles for this month |
From: "Christopher Glaeser" <cdg@nullstone.com>
Newsgroups: comp.compilers
Date: Tue, 12 May 2009 10:46:22 -0700
Organization: Compilers Central
References: 09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050 09-05-055
Keywords: optimize, C
Posted-Date: 12 May 2009 14:19:10 EDT

> The issue under discussions was that the optimizations I mentioned
> would change the register allocation, and that would result in changed
> values for uninitialized variables and thus altered behaviour. To fix
> that one actually does not need to initialize all variables (unlike
> what I wrote), only variables that may be born in registers,
> i.e. scalars. I don't think that's impractical.


The back flips needed to define undefined behavior in a language like
C is pretty far reaching. I only mentioned register allocation
because I didn't know you were advocating that the compiler needs to
initialize local scalar variables. Optimizations like copy
propagation and common subexpression elimination can also affect stack
allocation, which in turn, can affect the values of uninitialized
local arrays. Even a simple bug fix to a new release in a compiler
can affect the behavior of C programs that have undefined behavior.
It's not clear where pulling on this thread would end? Do you
advocate initializing local arrays too, and if not, why not?


> And yes, as I mentioned, there are certain cases (like out-of-bounds
> array accesses) where preservation of behaviour in all cases is
> impractical, and the benefits derived from it are vanishingly small.
> But still, that's a good ideal for optimizer writers to strive for,
> even if they cannot achieve it in all cases.


Given that you have tossed out-of-bounds array access into the
too-hard pile, are you also tossing undefined pointer use into the
too-hard pile as well? Given that pointers are so pervasive in C,
doesn't this miss one of the more common reasons why incorrect
programs can change behavior when optimized?


More to the point, I still don't understand your basic position. In
your original post, you accussed some compiler writers of being
"apologists" becuase they designed the optimizer to the lanauge
standard and you asserted that they should be designing the optimizer
to maintain the behavior of programs that use undefined behavior, and
then made some room for ignoring behavior like out-of-bound arrays.
This exception seems a bit arbitrary. How is a compiler writer to
know if they are an apologist?


Best,
Christopher


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.