summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprComplex.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [complex] Teach Clang to preserve different-type operands to arithmeticChandler Carruth2014-10-111-35/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-1/+1
| | | | llvm-svn: 209272
* Change PGO instrumentation to compute counts in a separate AST traversal.Bob Wilson2014-02-171-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* CodeGen: Rename adjustFallThroughCount -> adjustForControlFlowJustin Bogner2014-01-131-2/+2
| | | | | | | | 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
* CodeGen: Initial instrumentation based PGO implementationJustin Bogner2014-01-061-1/+7
| | | | llvm-svn: 198640
* Add front-end infrastructure now address space casts are in LLVM IR.David Tweed2013-12-111-0/+1
| | | | | | | | | | 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
* CodeGen: WhitespaceJustin Bogner2013-11-221-5/+5
| | | | llvm-svn: 195437
* Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occursNick Lewycky2013-10-021-16/+21
| | | | | | when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
* Make IgnoreParens() look through ChooseExprs.Eli Friedman2013-07-201-1/+1
| | | | | | | | | | | | | 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
* Propagate alignment for _ComplexJF Bastien2013-07-171-6/+20
| | | | | | | | _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
* Fix crash on complex constant zero.Eli Friedman2013-07-161-3/+3
| | | | | | Fixes <rdar://problem/14442543>. llvm-svn: 186452
* Add support for complex compound assignments where the LHS is a scalar.Eli Friedman2013-06-121-34/+64
| | | | | | Fixes <rdar://problem/11224126> and PR12790. llvm-svn: 183821
* Make sure we don't emit invalid IR for StmtExprs with complex cleanups.Eli Friedman2013-06-101-1/+3
| | | | | | Fixes <rdar://problem/14074868>. llvm-svn: 183699
* C++1y: Allow aggregates to have default initializers.Richard Smith2013-04-201-0/+4
| | | | | | | | | | | 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
* Promote atomic type sizes up to a power of two, capped byJohn McCall2013-03-071-1/+6
| | | | | | | | MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
* Change hasAggregateLLVMType, which conflates complex andJohn McCall2013-03-071-58/+56
| | | | | | | | | | | | | | | 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
* Implement OpenCL event_t as Clang builtin type, including event_t related ↵Guy Benyei2013-01-201-0/+1
| | | | | | OpenCL restrictions (OpenCL 1.2 spec 6.9) llvm-svn: 172973
* Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate toChandler Carruth2013-01-021-2/+2
| | | | | | | | reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-1/+1
| | | | | | | | | | | | | 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
* Simplify: replace getContext().getLangOpts() with just getLangOpts().Richard Smith2012-11-011-2/+2
| | | | llvm-svn: 167261
* Change the representation of builtin functions in the ASTEli Friedman2012-08-311-0/+1
| | | | | | | | | (__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
* Unify naming of LangOptions variable/get function across the Clang stack ↵David Blaikie2012-03-111-2/+2
| | | | | | | | | | (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
* Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr toJohn McCall2012-03-101-11/+4
| | | | | | | | 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
* Unify the BlockDeclRefExpr and DeclRefExpr paths so thatJohn McCall2012-03-101-2/+18
| | | | | | | | we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
* Add missing code for compound literals of complex type. ↵Eli Friedman2012-02-271-0/+4
| | | | | | <rdar://problem/10938628> llvm-svn: 151549
* Generate an AST for the conversion from a lambda closure type to aDouglas Gregor2012-02-221-0/+1
| | | | | | | | | | | | | | | block pointer that returns a block literal which captures (by copy) the lambda closure itself. Some aspects of the block literal are left unspecified, namely the capture variable (which doesn't actually exist) and the body (which will be filled in by IRgen because it can't be written as an AST). Because we're switching to this model, this patch also eliminates tracking the copy-initialization expression for the block capture of the conversion function, since that information is now embedded in the synthesized block literal. -1 side tables FTW. llvm-svn: 151131
* Split reinterpret_casts of member pointers out from CK_BitCast; thisJohn McCall2012-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | | is general goodness because representations of member pointers are not always equivalent across member pointer types on all ABIs (even though this isn't really standard-endorsed). Take advantage of the new information to teach IR-generation how to do these reinterprets in constant initializers. Make sure this works when intermingled with hierarchy conversions (although this is not part of our motivating use case). Doing this in the constant-evaluator would probably have been better, but that would require a *lot* of extra structure in the representation of constant member pointers: you'd really have to track an arbitrary chain of hierarchy conversions and reinterpretations in order to get this right. Ultimately, this seems less complex. I also wasn't quite sure how to extend the constant evaluator to handle foldings that we don't actually want to treat as extended constant expressions. llvm-svn: 150551
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-1/+0
| | | | llvm-svn: 148577
* Some improvements to the handling of C11 atomic types:David Chisnall2012-01-161-0/+4
| | | | | | | | | | | | | | | | | | - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
* Revert r147664; it's breaking clang regression tests.Eli Friedman2012-01-061-1/+1
| | | | llvm-svn: 147681
* Silence GCC warnings.Jakub Staszak2012-01-061-1/+1
| | | | llvm-svn: 147664
* Enter the cleanups for a block outside the enclosingJohn McCall2011-11-101-1/+3
| | | | | | | | | | | | full-expression. Naturally they're inactive before we enter the block literal expression. This restores the intended behavior that blocks belong to their enclosing scope. There's a useful -O0 / compile-time optimization that we're missing here with activating cleanups following straight-line code from their inactive beginnings. llvm-svn: 144268
* Rip out CK_GetObjCProperty.John McCall2011-11-071-1/+0
| | | | llvm-svn: 143910
* Rip the ObjCPropertyRef l-value kind out of IR-generation.John McCall2011-11-071-28/+5
| | | | llvm-svn: 143908
* Change the AST representation of operations on Objective-CJohn McCall2011-11-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
* Restore r142914 and r142915, now with missing file and apparentJohn McCall2011-10-251-1/+1
| | | | | | GCC compiler workaround. llvm-svn: 142931
* Revert r142914 and r142915, due to possibly missing file.NAKAMURA Takumi2011-10-251-1/+1
| | | | | | r142914: "Introduce a placeholder type for "pseudo object"" r142915: "Pull the pseudo-object stuff into its own file." llvm-svn: 142921
* Introduce a placeholder type for "pseudo object"John McCall2011-10-251-1/+1
| | | | | | | | | | | | | | | expressions: expressions which refer to a logical rather than a physical l-value, where the logical object is actually accessed via custom getter/setter code. A subsequent patch will generalize the AST for these so that arbitrary "implementing" sub-expressions can be provided. Right now the only client is ObjC properties, but this should be generalizable to similar language features, e.g. Managed C++'s __property methods. llvm-svn: 142914
* Initial implementation of __atomic_* (everything except __atomic_is_lock_free).Eli Friedman2011-10-111-0/+4
| | | | llvm-svn: 141632
* de-tmpify clang.Benjamin Kramer2011-09-271-24/+24
| | | | llvm-svn: 140637
* Removing a bunch of dead returns/breaks after llvm_unreachables.David Blaikie2011-09-231-1/+0
| | | | llvm-svn: 140407
* Switch assert(0/false) llvm_unreachable.David Blaikie2011-09-231-1/+1
| | | | llvm-svn: 140367
* Add list initialization for complex numbers in C. Essentially, this allows ↵Eli Friedman2011-09-191-1/+8
| | | | | | | | "_Complex float x = {1.0f, 2.0f};". See changes to docs/LanguageExtensions.html for a longer description. <rdar://problem/9397672>. llvm-svn: 140090
* Rename the ARC cast kinds to start with "ARC".John McCall2011-09-101-4/+4
| | | | llvm-svn: 139466
* When converting a block pointer to an Objective-C pointer type, extendJohn McCall2011-09-101-0/+1
| | | | | | | | | | | the lifetime of the block by copying it to the heap, or else we'll get a dangling reference because the code working with the non-block-typed object will not know it needs to copy. There is some danger here, e.g. with assigning a block literal to an unsafe variable, but, well, it's an unsafe variable. llvm-svn: 139451
* Give conversions of block pointers to ObjC pointers a different cast kindJohn McCall2011-09-091-1/+2
| | | | | | | | than conversions of C pointers to ObjC pointers. In order to ensure that we've caught every case, add asserts to CastExpr that strictly determine which cast kind is used for which kind of bit cast. llvm-svn: 139352
* blocks: Support capturing complex variable in block.Fariborz Jahanian2011-09-021-0/+1
| | | | | | // rdar://10033896 llvm-svn: 139041
* revert patch in r139020Fariborz Jahanian2011-09-021-1/+5
| | | | llvm-svn: 139029
* blocks: Support capturing complex variable in block.Fariborz Jahanian2011-09-021-5/+1
| | | | | | // rdar://10033896 llvm-svn: 139020
* de-constify llvm::Type, patch by David Blaikie!Chris Lattner2011-07-181-3/+3
| | | | llvm-svn: 135370
OpenPOWER on IntegriCloud