Now CodeGenFunction is responsible for looking at sanitizer blacklist
(in CodeGenFunction::StartFunction) and turning off instrumentation,
if necessary.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212501 91177308-0d34-0410-b5e6-96231b3b80d8
Codegen is still missing (and I won't work on that), but __leave is now
as implemented as __try and friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212425 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the dead code, and refines the
getEHResumeBlock() slightly.
The CleanupHackLevel was a hack to the old exception
handling intrinsics, which have several issues with function
inliner.
Since LLVM 3.0, the new landingpad and resume instructions
are added to LLVM IR. With the new exception handling
mechanism, most of the issues are fixed now. We should
always use these instructions to implement the exception
handling code nowadays, and we don't need the hack any more.
Besides, the `CleanupHackLevel` is a compile-time constant,
thus other cases have been considered as dead code for a while.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212097 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211113 91177308-0d34-0410-b5e6-96231b3b80d8
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210137 91177308-0d34-0410-b5e6-96231b3b80d8
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210079 91177308-0d34-0410-b5e6-96231b3b80d8
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209578 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements global named registers in Clang, lowering to the just
created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue
had to be created (Register), which just adds support to carry the metadata
node containing the name of the register. Two new methods to emit loads and
stores interoperate with another to emit the named metadata node.
No guarantees are being made and only non-allocatable global variable named
registers are being supported. Local named register support is unchanged.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209149 91177308-0d34-0410-b5e6-96231b3b80d8
CapturedStmt was being ignored by instrumentation based profiling, and
its counters attributed to the containing function. Instead, we need
to treat this as a top level entity, like we do with blocks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206231 91177308-0d34-0410-b5e6-96231b3b80d8
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205999 91177308-0d34-0410-b5e6-96231b3b80d8
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205100 91177308-0d34-0410-b5e6-96231b3b80d8
This extends the intrinsic lookup table format slightly, and adds
entries for use the shared ARM/AArch64 definitions. The benefit is
currently smaller than for the SISD intrinsics (there's more custom
code implementing this set), but a few lines are saved and there's
scope for future expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201848 91177308-0d34-0410-b5e6-96231b3b80d8
This extracts the table-driven intrinsic lookup phase into a separate
function, to be used by EmitCommonNeonBuiltinExpr soon.
It also simplifies the logic used in that lookup, since VectorCastArgN
and ScalarArgN were actually identical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201847 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201528 91177308-0d34-0410-b5e6-96231b3b80d8
properties by fixing shouldBindAsLValue to accept arrays
(like record types) because we always manipulate
them in memory. Patch suggested by John MaCall.
// rdar://15610943
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201428 91177308-0d34-0410-b5e6-96231b3b80d8
When a non-trivial parameter is present, clang now gathers up all the
parameters that lack inreg and puts them into a packed struct. MSVC
always aligns each parameter to 4 bytes and no more, so this is a pretty
simple struct to lay out.
On win64, non-trivial records are passed indirectly. Prior to this
change, clang was incorrectly using byval on win64.
I'm able to self-host a working clang with this change and additional
LLVM patches.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2636
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200597 91177308-0d34-0410-b5e6-96231b3b80d8
This extends the refactoring to the whole of the first block of
trivial correspondences (as a fairly arbitrary boundary).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200472 91177308-0d34-0410-b5e6-96231b3b80d8
As a starting point, this moves the CodeGen for NEON permutation
instructions (vtrn, vzip, vuzp) into a new shared function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200471 91177308-0d34-0410-b5e6-96231b3b80d8
I misunderstood the discussion on this. The complexity here is
justified by the malloc overhead it saves.
This reverts commit r199302.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199700 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
Way back in r129652 we tried to avoid emitting an empty block at -O0
for switch cases that did nothing but break. This led to a poor
debugging experience as reported in PR9796, so we disabled the
optimization for -O0 but left it in for higher optimization levels in
r154420.
Since the whole point of this was to improve -O0, it's silly to keep
the complexity at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199302 91177308-0d34-0410-b5e6-96231b3b80d8
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198699 91177308-0d34-0410-b5e6-96231b3b80d8
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198686 91177308-0d34-0410-b5e6-96231b3b80d8
the lexical block formed by the compound statement that is the function
body.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198461 91177308-0d34-0410-b5e6-96231b3b80d8
Unlike Itanium's VTTs, the 'most derived' boolean or bitfield is the
last parameter for non-variadic constructors, rather than the second.
For variadic constructors, the 'most derived' parameter comes after the
'this' parameter. This affects constructor calls and constructor decls
in a variety of places.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D2405
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197518 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
MSVC destroys arguments in the callee from left to right. Because C++
objects have to be destroyed in the reverse order of construction, Clang
has to construct arguments from right to left and destroy arguments from
left to right.
This patch fixes the ordering by reversing the order of evaluation of
all call arguments under the MS C++ ABI.
Fixes PR18035.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2275
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196402 91177308-0d34-0410-b5e6-96231b3b80d8
Alexey Bataev