1 files changed, 17 insertions, 2 deletions

diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index d8c04651f0a..53ab11b430c 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/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.