Commit Graph

432 Commits

Author SHA1 Message Date
Manman Ren c089074aa5 revert r177211 due to its potential issues
llvm-svn: 177222
2013-03-16 04:47:38 +00:00
Manman Ren 58dd990c11 Exploit this-return of a callsite in a this-return function.
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.

We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.

rdar://12818789

llvm-svn: 177211
2013-03-16 00:11:09 +00:00
Jordan Rose 5c38272c1a ArrayRef-ize ASTContext::getFunctionType and Sema::BuildFunctionType.
No (intended) functionality change.

llvm-svn: 176726
2013-03-08 21:51:21 +00:00
Joey Gouly aba589cceb Add support for the OpenCL attribute 'vec_type_hint'.
Patch by Murat Bolat!

llvm-svn: 176686
2013-03-08 09:42:32 +00:00
John McCall 47fb950871 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
2013-03-07 21:37:08 +00:00
John McCall 882987f30c Use the actual ABI-determined C calling convention for runtime
calls and declarations.

LLVM has a default CC determined by the target triple.  This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention.  Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect.  However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility.  Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile;  so it's quite
important to get this right.

Defining runtime functions locally is quite common in embedded
applications.

llvm-svn: 176286
2013-02-28 19:01:20 +00:00
David Blaikie 1d969f42a0 Prefer 'and' over '&' in comments.
Post commit code review feedback from Matt Beaumont-Gay on r174248.

llvm-svn: 175969
2013-02-23 19:20:56 +00:00
Lang Hames bf122744e5 Re-apply r174919 - smarter copy/move assignment/construction, with fixes for
bitfield related issues.

The original commit broke Takumi's builder. The bug was caused by bitfield sizes
being determined by their underlying type, rather than the field info. A similar
issue with bitfield alignments showed up on closer testing. Both have been fixed
in this patch.

llvm-svn: 175389
2013-02-17 07:22:09 +00:00
Timur Iskhodzhanov ee6bc53365 Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058
llvm-svn: 175045
2013-02-13 08:37:51 +00:00
Lang Hames 697b004219 Backing out r174919 while I investigate a self-host bug on Takumi's builder.
llvm-svn: 174925
2013-02-12 00:44:43 +00:00
Lang Hames 5824a4f1b0 When generating IR for default copy-constructors, copy-assignment operators,
move-constructors and move-assignment operators, use memcpy to copy adjacent
POD members.

Previously, classes with one or more Non-POD members would fall back on
element-wise copies for all members, including POD members. This often
generated a lot of IR. Without padding metadata, it wasn't often possible
for the LLVM optimizers to turn the element-wise copies into a memcpy.

This code hasn't yet received any serious tuning. I didn't see any serious
regressions on a self-hosted clang build, or any of the nightly tests, but
I think it's important to get this out in the wild to get more testing.
Insights, feedback and comments welcome.

Many thanks to David Blaikie, Richard Smith, and especially John McCall for
their help and feedback on this work.

llvm-svn: 174919
2013-02-11 23:44:11 +00:00
David Blaikie b7d1e1ff57 Revert r174246, accidentally committed.
This reverts commit 1513eb9284c23acfd19cf742b95996fbb11ca741.

llvm-svn: 174249
2013-02-02 00:39:32 +00:00
David Blaikie cbf40d22bf Sentenc-ify comment added in r174206.
Based on post-commit review by Paul Robinson.

llvm-svn: 174248
2013-02-02 00:36:58 +00:00
David Blaikie ef50169a03 Basics
llvm-svn: 174246
2013-02-02 00:34:16 +00:00
David Blaikie 357aafb566 Fix exception handling line table problems introduced by r173593
r173593 made us a little too eager to associate all code at the end of a
function with the user-written 'return' line. This caused problems with
breakpoints as they'd be set in exception handling code preceeding the
actual non-exception return handling code, leading to the breakpoint never
being hit in non-exceptional execution.

This change restores the pre-r173593 exception handling line information where
the cleanup code is associated with the '}' not the return line.

llvm-svn: 174206
2013-02-01 19:09:49 +00:00
David Blaikie 0a21d0da17 PR14566: Debug Info: avoid top level lexical blocks in functions
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.

Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.

llvm-svn: 173593
2013-01-26 22:16:26 +00:00
Will Dietz f54319c891 [ubsan] Add support for -fsanitize-blacklist
llvm-svn: 172808
2013-01-18 11:30:38 +00:00
Dmitri Gribenko f857950d39 Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

llvm-svn: 172323
2013-01-12 19:30:44 +00:00
Chandler Carruth ffd5551bc7 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
2013-01-02 11:45:17 +00:00
Bill Wendling 207f05369d Rename llvm::Attributes to llvm::Attribute.
llvm-svn: 170722
2012-12-20 19:27:06 +00:00
Bill Wendling 4442605f18 Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here.
llvm-svn: 170721
2012-12-20 19:22:21 +00:00
Bill Wendling 7967fc14b9 Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.
llvm-svn: 170500
2012-12-19 07:18:12 +00:00
Benjamin Kramer 7464efcac8 Unbreak the clang build after r169712.
llvm-svn: 169713
2012-12-09 21:58:24 +00:00
Chandler Carruth 3a02247dc9 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
2012-12-04 09:13:33 +00:00
Michael Ilseman 7a167eef2f Have clang use LLVM IR's fast-math flags when in FastMath or FiniteMathOnly modes. Test cases included.
llvm-svn: 169191
2012-12-04 00:36:06 +00:00