cc accepts the undocumented option -funroll-loops. As it is undocumented, one has no idea what it does. If cc does unrolling, there appears to be no way to control the level of unrolling. Please fix.
A lot of options are unfortunately undocumented with clang :(... see this thread for more details: http://clang-developers.42468.n3.nabble.com/clang-1-3-4-manpage-documentation-is-sparse-need-help-figuring-out-available-options-in-compiler-td4042738.html (tl;dr: submit a patch to our project and we'll accept it :/...).
Oh yuck. Long lines and new sentences starting in the middle of a line. diff -u cc.1.orig cc.1 --- cc.1.orig 2016-01-05 11:57:16.699107000 -0800 +++ cc.1 2016-01-05 12:12:47.718444000 -0800 @@ -251,8 +251,15 @@ through Clang compiled stack frames. This is on by default in x86-64. .It Sy -ftrapv Generate code to catch integer overflow errors. Signed integer overflow is -undefined in C, with this flag, extra code is generated to detect this and abort -when it happens. +undefined in C, with this flag, extra code is generated to detect this and +abort when it happens. +.It Sy -funroll-loops +This option is accepted by the compiler, but testing with simply +loops suggests that apparently does nothing. +Surprisingly, +.Nm +does not issue a warning about the omission of what can only be characterized +as a basic optimization. .It Sy -fvisibility This flag sets the default visibility level. .It Sy -fcommon
You're absolutely correct that clang can do a much better job of documentation its options. That said, since the FreeBSD project uses clang as a pure third party compiler, and isn't in the business of writing a compiler, I am closing this bug without action. It isn't exactly "work's as intended" so much as "we're the wrong people to fix this issue". It can be argued if we should have taken this into account when we made the switch etc. but this bug is the wrong place for that argument.