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
Instead of storing the vtable offset directly in the function pointer and
doing a branch to check for virtualness at each call site, the MS ABI
generates a thunk for calling the function at a specific vtable offset,
and puts that in the function pointer.
This patch adds support for emitting such thunks. However, it doesn't support
pointers to virtual member functions that are variadic, have an incomplete
aggregate return type or parameter, or are overriding a function in a virtual
base class.
Differential Revision: http://llvm-reviews.chandlerc.com/D2104
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194827 91177308-0d34-0410-b5e6-96231b3b80d8
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194055 91177308-0d34-0410-b5e6-96231b3b80d8
These IR instructions are undefined when the amount is equal to operand
size, but NEON right shifts support such shifts. Work around that by
emitting a different IR in these cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191953 91177308-0d34-0410-b5e6-96231b3b80d8
The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator.
This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM.
A few minor changes:
- per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
- I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
- Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191634 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we silently omit the code in the try and finally bodies, which
is pretty bad. This way we fail loudly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190809 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189320.
Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping
these around - though it still seems like those tasks could be solved by
a tool just using the symbol table. In a very small number of cases,
thunks may be inlined & debug info might be able to save profilers &
similar tools from misclassifying those cases as part of the caller.
The extra changes here plumb through the VarDecl for various cases to
CodeGenFunction - this provides better fidelity through a few APIs but
generally just causes the CGF::StartFunction to fallback to using the
name of the IR function as the name in the debug info.
The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The
two names that go missing (in favor of only emitting those names as
linkage names) are names that can be demangled - emitting them only as
the linkage name should encourage tools to do just that.
Again, thanks to Dinesh Dwivedi for investigation/work on this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189421 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenFunction is run on only one function - a new object is made for
each new function. I would add an assertion/flag to this effect, but
there's an exception: ObjC properties involve emitting helper functions
that are all emitted by the same CodeGenFunction object, so such a check
is not possible/correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189277 91177308-0d34-0410-b5e6-96231b3b80d8
They were mostly copy&paste of each other, move it to CodeGenFunction. Of course
the two implementations have diverged over time; the one in CGExprCXX seems to
be the more modern one so I picked that one and moved it to CGClass which feels
like a better home for it. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189203 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188707 91177308-0d34-0410-b5e6-96231b3b80d8
Restore it after each argument is emitted. This fixes the scope info for
inlined subroutines inside of function argument expressions. (E.g.,
anything STL).
rdar://problem/12592135
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187240 91177308-0d34-0410-b5e6-96231b3b80d8
Tim Northover