[llvm] r235825 - Add two new items to PerformanceTips

[Philip Reames]

Author: reames
Date: Sun Apr 26 17:15:18 2015
New Revision: 235825

URL: http://llvm.org/viewvc/llvm-project?rev=235825&view=rev
Log:
Add two new items to PerformanceTips

1) Turns out we're not great at recognizing redundant checks when one is a != and the other is an ==.  This is a bug, but it's one that matters to frontend authors.

2) Frontends shouldn't use intrinsics unless strictly neccessary.  This has been pretty widely proven by this point and is good to document.


Modified:
    llvm/trunk/docs/Frontend/PerformanceTips.rst

Modified: llvm/trunk/docs/Frontend/PerformanceTips.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Frontend/PerformanceTips.rst?rev=235825&r1=235824&r2=235825&view=diff
==============================================================================
--- llvm/trunk/docs/Frontend/PerformanceTips.rst (original)
+++ llvm/trunk/docs/Frontend/PerformanceTips.rst Sun Apr 26 17:15:18 2015
@@ -55,8 +55,7 @@ Other things to consider
 
 #. Add nsw/nuw flags as appropriate.  Reasoning about overflow is 
    generally hard for an optimizer so providing these facts from the frontend 
-   can be very impactful.  For languages which need overflow semantics, 
-   consider using the :ref:`overflow intrinsics <int_overflow>`.
+   can be very impactful.  
 
 #. Use fast-math flags on floating point operations if legal.  If you don't 
    need strict IEEE floating point semantics, there are a number of additional 
@@ -142,6 +141,22 @@ Other things to consider
    perform badly with confronted with such structures.  The only exception to 
    this guidance is that a unified return block with high in-degree is fine.
 
+#. When checking a value against a constant, emit the check using a consistent
+   comparison type.  The GVN pass _will_ optimize redundant equalities even if
+   the type of comparison is inverted, but GVN only runs late in the pipeline.
+   As a result, you may miss the oppurtunity to run other important 
+   optimizations.  Improvements to EarlyCSE to remove this issue are tracked in 
+   Bug 23333.
+
+#. Avoid using arithmetic intrinsics unless you are _required_ by your source 
+   language specification to emit a particular code sequence.  The optimizer 
+   is quite good at reasoning about general control flow and arithmetic, it is
+   not anywhere near as strong at reasoning about the various intrinsics.  If 
+   profitable for code generation purposes, the optimizer will likely form the 
+   intrinsics itself late in the optimization pipeline.  It is _very_ rarely 
+   profitable to emit these directly in the language frontend.  This item
+   explicitly includes the use of the :ref:`overflow intrinsics <int_overflow>`.
+
 p.s. If you want to help improve this document, patches expanding any of the 
 above items into standalone sections of their own with a more complete 
 discussion would be very welcome.