llvm-project/clang
Chandler Carruth 54c2910692 The only useful loop unrolling flag to give realistically is
'-fno-unroll-loops'. The option to the backend is even called
'DisableUnrollLoops'. This is precisely the form that Clang *didn't*
support. We didn't recognize the flag, we didn't pass it to the CC1
layer, and even if we did we wouldn't use it. Clang only inspected the
positive form of the flag, and only did so to enable loop unrolling when
the optimization level wasn't high enough. This only occurs for an
optimization level that even has a chance of running the loop unroller
when optimizing for size.

This commit wires up the 'no' variant, and switches the code to actually
follow the standard flag pattern of using the last flag and allowing
a flag in either direction to override the default.

I think this is still wrong. I don't know why we disable the loop
unroller entirely *from Clang* when optimizing for size, as the loop
unrolling pass *already has special logic* for the case where the
function is attributed as optimized for size! We should really be
trusting that. Maybe in a follow-up patch, I don't really want to change
behavior here.

llvm-svn: 187969
2013-08-08 08:34:35 +00:00
..
INPUTS
bindings [libclang] Expose the rest of the array types. 2013-07-23 17:36:21 +00:00
docs DataFlowSanitizer; Clang changes. 2013-08-07 22:47:34 +00:00
examples Remove unused header. 2013-06-26 13:49:47 +00:00
include The only useful loop unrolling flag to give realistically is 2013-08-08 08:34:35 +00:00
lib The only useful loop unrolling flag to give realistically is 2013-08-08 08:34:35 +00:00
runtime DataFlowSanitizer; Clang changes. 2013-08-07 22:47:34 +00:00
test The only useful loop unrolling flag to give realistically is 2013-08-08 08:34:35 +00:00
tools Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... 2013-08-06 01:03:05 +00:00
unittests Revert r187935 "Support for double width characters." 2013-08-08 02:19:56 +00:00
utils AArch64: initial NEON support 2013-08-01 09:23:19 +00:00
www Update status of support for variable templates on website. 2013-08-06 07:37:09 +00:00
.arcconfig
.gitignore
CMakeLists.txt clang-cl: add support for the /? and /help options 2013-07-27 00:23:45 +00:00
CODE_OWNERS.TXT Revert r185557 as it was a bit (a lot) premature. 2013-07-03 20:37:50 +00:00
INSTALL.txt Reverting test commit 2013-06-07 05:33:21 +00:00
LICENSE.TXT
Makefile
ModuleInfo.txt
NOTES.txt
README.txt

README.txt

//===----------------------------------------------------------------------===//
// C Language Family Front-end
//===----------------------------------------------------------------------===//

Welcome to Clang.  This is a compiler front-end for the C family of languages
(C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM
compiler infrastructure project.

Unlike many other compiler frontends, Clang is useful for a number of things
beyond just compiling code: we intend for Clang to be host to a number of
different source level tools.  One example of this is the Clang Static Analyzer.

If you're interested in more (including how to build Clang) it is best to read
the relevant web sites.  Here are some pointers:

Information on Clang:              http://clang.llvm.org/
Building and using Clang:          http://clang.llvm.org/get_started.html
Clang Static Analyzer:             http://clang-analyzer.llvm.org/
Information on the LLVM project:   http://llvm.org/

If you have questions or comments about Clang, a great place to discuss them is
on the Clang development mailing list:
  http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

If you find a bug in Clang, please file it in the LLVM bug tracker:
  http://llvm.org/bugs/