| #
aa3e9f5a |
| 17-Oct-2014 |
Joerg Sonnenberger <[email protected]> |
complex long double support for PowerPC
llvm-svn: 220034
|
| #
686de241 |
| 11-Oct-2014 |
Chandler Carruth <[email protected]> |
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math.
This should fix the windows build bots that started having trouble here and generally fix complex libcall emi
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math.
This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code).
llvm-svn: 219565
show more ...
|
| #
a216cad0 |
| 11-Oct-2014 |
Chandler Carruth <[email protected]> |
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information.
For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case.
However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations.
The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%.
In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm.
Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change.
Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding.
Differential Revision: http://reviews.llvm.org/D5698
llvm-svn: 219557
show more ...
|
|
Revision tags: llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
8a13c418 |
| 21-May-2014 |
Craig Topper <[email protected]> |
[C++11] Use 'nullptr'. CodeGen edition.
llvm-svn: 209272
|
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
bf854f0f |
| 17-Feb-2014 |
Bob Wilson <[email protected]> |
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign counters to the ASTs and then propagated the count v
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign counters to the ASTs and then propagated the count values during codegen. This patch now adds a separate AST traversal prior to codegen for the -fprofile-instr-use option to propagate the count values. The counts are then saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the list but never committed) used 3 counters for every loop. Justin improved it to move 2 of those counters into the less-frequently executed breaks and continues, but that turned out to produce wrong count values in some cases. The solution requires visiting a loop body before the condition so that the count for the condition properly includes the break and continue counts. Changing codegen to visit a loop body first would be a fairly invasive change, but with a separate AST traversal, it is easy to control the order of traversal. I've added a testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for a loop from 3 to 1. We no longer need dedicated counters for breaks and continues, since we can just use the propagated count values when visiting breaks and continues.
To make this work, I needed to make a change to the way we count case statements, going back to my original approach of not including the fall-through in the counter values. This was necessary because there isn't always an AST node that can be used to record the fall-through count. Now case statements are handled the same as default statements, with the fall-through paths branching over the counter increments. While I was at it, I also went back to using this approach for do-loops -- omitting the fall-through count into the loop body simplifies some of the calculations and make them behave the same as other loops. Whenever we start using this instrumentation for coverage, we'll need to add the fall-through counts into the counter values.
llvm-svn: 201528
show more ...
|
| #
0718a3a4 |
| 13-Jan-2014 |
Justin Bogner <[email protected]> |
CodeGen: Rename adjustFallThroughCount -> adjustForControlFlow
adjustFallThroughCount isn't a good name, and the documentation was even worse. This commit attempts to clarify what it's for and when
CodeGen: Rename adjustFallThroughCount -> adjustForControlFlow
adjustFallThroughCount isn't a good name, and the documentation was even worse. This commit attempts to clarify what it's for and when to use it.
llvm-svn: 199139
show more ...
|
| #
ef512b99 |
| 06-Jan-2014 |
Justin Bogner <[email protected]> |
CodeGen: Initial instrumentation based PGO implementation
llvm-svn: 198640
|
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3 |
|
| #
e1468322 |
| 11-Dec-2013 |
David Tweed <[email protected]> |
Add front-end infrastructure now address space casts are in LLVM IR.
With the introduction of explicit address space casts into LLVM, there's a need to provide a new cast kind the front-end can crea
Add front-end infrastructure now address space casts are in LLVM IR.
With the introduction of explicit address space casts into LLVM, there's a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA and code to produce address space casts from those kinds when appropriate.
Patch by Michele Scandale!
llvm-svn: 197036
show more ...
|
|
Revision tags: llvmorg-3.4.0-rc2 |
|
| #
0f06606b |
| 22-Nov-2013 |
Justin Bogner <[email protected]> |
CodeGen: Whitespace
llvm-svn: 195437
|
|
Revision tags: llvmorg-3.4.0-rc1 |
|
| #
2d84e842 |
| 02-Oct-2013 |
Nick Lewycky <[email protected]> |
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion.
llvm-svn: 191808
|
| #
75807f23 |
| 20-Jul-2013 |
Eli Friedman <[email protected]> |
Make IgnoreParens() look through ChooseExprs.
This is the same way GenericSelectionExpr works, and it's generally a more consistent approach.
A large part of this patch is devoted to caching the va
Make IgnoreParens() look through ChooseExprs.
This is the same way GenericSelectionExpr works, and it's generally a more consistent approach.
A large part of this patch is devoted to caching the value of the condition of a ChooseExpr; it's needed to avoid threading an ASTContext into IgnoreParens().
Fixes <rdar://problem/14438917>.
llvm-svn: 186738
show more ...
|
| #
27dcbb24 |
| 17-Jul-2013 |
JF Bastien <[email protected]> |
Propagate alignment for _Complex
_Complex load/store didn't have their alignment set properly, which was visible when GCC's torture tests use volatile _Complex.
Update some existing tests to check
Propagate alignment for _Complex
_Complex load/store didn't have their alignment set properly, which was visible when GCC's torture tests use volatile _Complex.
Update some existing tests to check for alignment, and add a new test which also has over-aligned volatile _Complex (since the imaginary part shouldn't be overaligned, only the real part).
llvm-svn: 186490
show more ...
|
| #
64f23918 |
| 16-Jul-2013 |
Eli Friedman <[email protected]> |
Fix crash on complex constant zero.
Fixes <rdar://problem/14442543>.
llvm-svn: 186452
|
|
Revision tags: llvmorg-3.3.1-rc1 |
|
| #
f045007f |
| 12-Jun-2013 |
Eli Friedman <[email protected]> |
Add support for complex compound assignments where the LHS is a scalar.
Fixes <rdar://problem/11224126> and PR12790.
llvm-svn: 183821
|
| #
4871a46c |
| 10-Jun-2013 |
Eli Friedman <[email protected]> |
Make sure we don't emit invalid IR for StmtExprs with complex cleanups.
Fixes <rdar://problem/14074868>.
llvm-svn: 183699
|
|
Revision tags: llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1 |
|
| #
852c9db7 |
| 20-Apr-2013 |
Richard Smith <[email protected]> |
C++1y: Allow aggregates to have default initializers.
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default ini
C++1y: Allow aggregates to have default initializers.
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can refer to the initialized object via its 'this' pointer, we need to make sure that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
show more ...
|
| #
a8ec7eb9 |
| 07-Mar-2013 |
John McCall <[email protected]> |
Promote atomic type sizes up to a power of two, capped by MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto.
llvm-svn: 176658
|
| #
47fb9508 |
| 07-Mar-2013 |
John McCall <[email protected]> |
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distingu
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other.
llvm-svn: 176656
show more ...
|
| #
1b4fb3e0 |
| 20-Jan-2013 |
Guy Benyei <[email protected]> |
Implement OpenCL event_t as Clang builtin type, including event_t related OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
| #
ffd5551b |
| 02-Jan-2013 |
Chandler Carruth <[email protected]> |
Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3 |
|
| #
3a02247d |
| 04-Dec-2012 |
Chandler Carruth <[email protected]> |
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered.
This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/util
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered.
This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files.
I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
show more ...
|
|
Revision tags: llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1 |
|
| #
9c6890a7 |
| 01-Nov-2012 |
Richard Smith <[email protected]> |
Simplify: replace getContext().getLangOpts() with just getLangOpts().
llvm-svn: 167261
|
| #
34866c77 |
| 31-Aug-2012 |
Eli Friedman <[email protected]> |
Change the representation of builtin functions in the AST (__builtin_* etc.) so that it isn't possible to take their address. Specifically, introduce a new type to represent a reference to a builtin
Change the representation of builtin functions in the AST (__builtin_* etc.) so that it isn't possible to take their address. Specifically, introduce a new type to represent a reference to a builtin function, and a new cast kind to convert it to a function pointer in the operand of a call. Fixes PR13195.
llvm-svn: 162962
show more ...
|
|
Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
| #
bbafb8a7 |
| 11-Mar-2012 |
David Blaikie <[email protected]> |
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris La
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
show more ...
|
| #
113bee05 |
| 10-Mar-2012 |
John McCall <[email protected]> |
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of t
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit.
llvm-svn: 152491
show more ...
|