[llvm] r235825 - Add two new items to PerformanceTips
listmail at philipreames.com
Sun Apr 26 15:15:18 PDT 2015
Date: Sun Apr 26 17:15:18 2015
New Revision: 235825
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.
--- 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.
More information about the llvm-commits