RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2024-12-04 10:04:33 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add two new items to PerformanceTips

Browse Source 
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
This commit is contained in:
Philip Reames 2015-04-26 22:15:18 +00:00
parent c4ab95d900
commit 77456809c4
1 changed files with 17 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/Frontend/PerformanceTips.rst
View File

@ -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.