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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235825 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/Frontend/PerformanceTips.rst b/docs/Frontend/PerformanceTips.rst
index d8c04651f0a0988078677361fc7d42a5ff47ba6c..53ab11b430c26cb02622e10d18adc04cc22419ff 100644 (file)
--- a/docs/Frontend/PerformanceTips.rst
+++ b/docs/Frontend/PerformanceTips.rst
@@ -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.