Re: Optimizing empty functions in C

"Christopher Glaeser" <cdg@nullstone.com>
17 Jun 2002 00:14:49 -0400

          From comp.compilers

Related articles
Optimizing empty functions in C wasowski@data.pl (Andrzej Wasowski) (2002-06-13)
Re: Optimizing empty functions in C snicol@apk.net (Scott Nicol) (2002-06-14)
Re: Optimizing empty functions in C joachim_d@gmx.de (Joachim Durchholz) (2002-06-14)
Re: Optimizing empty functions in C vbdis@aol.com (VBDis) (2002-06-14)
Re: Optimizing empty functions in C debray@CS.Arizona.EDU (Saumya K. Debray) (2002-06-14)
Re: Optimizing empty functions in C cdg@nullstone.com (Christopher Glaeser) (2002-06-17)
Re: Optimizing empty functions in C wasowski@data.pl (Andrzej Wasowski) (2002-06-20)
Re: Optimizing empty functions in C wasowski@data.pl (Andrzej Wasowski) (2002-06-20)
Re: Optimizing empty functions in C wasowski@data.pl (Andrzej Wasowski) (2002-06-20)
Re: Optimizing empty functions in C mlacey@microsoft.com (Mark Lacey \[MSFT\]) (2002-06-20)
Re: Optimizing empty functions in C dnovillo@redhat.com (Diego Novillo) (2002-06-28)
Re: Optimizing empty functions in C snicol@apk.net (Scott Nicol) (2002-06-28)
[4 later articles]
| List of all articles for this month |
From: "Christopher Glaeser" <cdg@nullstone.com>
Newsgroups: comp.compilers
Date: 17 Jun 2002 00:14:49 -0400
Organization: Concentric Internet Services
References: 02-06-025 02-06-048
Keywords: optimize, practice
Posted-Date: 17 Jun 2002 00:14:49 EDT

> When processing (the machine code resulting from) this code, our
> optimizer inlined the call to GC_noop(), then eliminated the
> dereference operation "*result" that evaluated the argument after
> inferring that it was unnecessary since it was not used.


This was once a common defect in many optimizers. About six years
ago, I analyzed twenty C compilers using many different types of loop
constructs with a volatile reference. Twelve of the compilers
incorrectly hoisted a volatile reference out of the loop for one or
more of the loop constructs. Some of the compilers were sensitive to
a particalur loop construct and data type. A collection of volatile
tests were added to the NULLSTONE suite to catch these defects using a
mechanism to update the value independent of the loop. This defect
appears to be less common today.


Best,
Christopher
http://www.nullstone.com/


Post a followup to this message

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