| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In llvm commit r243581, a reverse range adapter was added which allows
us to change code such as
for (auto I = Fields.rbegin(), E = Fields.rend(); I != E; ++I) {
in to
for (const FieldDecl *I : llvm::reverse(Fields))
This commit changes a few of the places in clang which are eligible to use
this new adapter.
llvm-svn: 243663
|
|
|
|
| |
llvm-svn: 242824
|
|
|
|
|
|
|
| |
The attribute '__declspec(noalias)' communicates that the function only
accesses memory pointed to by its pointer-typed arguments.
llvm-svn: 242728
|
|
|
|
|
|
|
|
| |
- Make it a proper random access iterator with a little help from iterator_adaptor_base
- Clean up users of magic dereferencing. The iterator should behave like an Expr **.
- Make it an implementation detail of Stmt. This allows inlining of the assertions.
llvm-svn: 242608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code in CGCall.cpp that loads up function arguments that need to be
coerced to a different type may in some cases ignore the fact that
the source of the argument is not naturally aligned. This may cause
incorrect code to be generated. In some places in CreateCoercedLoad,
we already have setAlignment calls to address this, but I ran into one
where it was missing, causing wrong code generation on SystemZ.
However, in that location, we do not actually know what alignment of
the source location we can rely on; the callers do not pass anything
to this routine. This is already an issue in other places in
CreateCoercedLoad; and the same problem exists for CreateCoercedStore.
To avoid pessimising code, and to fix the FIXMEs already in place,
this patch also adds an alignment argument to the CreateCoerced*
routines and uses it instead of forcing an alignment of 1. The
callers are changed to pass in the best information they have.
This actually requires changes in a number of existing test cases
since we now get better alignment in many places.
Differential Revision: http://reviews.llvm.org/D11033
llvm-svn: 241898
|
|
|
|
|
|
|
| |
Use const auto rather than duplicating the type name and fix the
error message when the attribute is applied to an incorrect entity.
llvm-svn: 241526
|
|
|
|
|
|
|
| |
This allows us to deal a bit more gracefully with inclusions done
by macros, token pasting, or just code layout/formatting.
llvm-svn: 241525
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to use clang's command line option "-ftrap-function" for LTO and
enable changing the trap function name on a per-call-site basis.
rdar://problem/21225723
Differential Revision: http://reviews.llvm.org/D10831
llvm-svn: 241306
|
|
|
|
|
|
|
| |
While there replace stable_sort of std::string with just sort, stability
is not necessary for "simple" value types. No functional change intended.
llvm-svn: 241299
|
|
|
|
|
|
|
| |
in order to make testing somewhat more feasible. Has the advantage
of making it easier to find target features as well.
llvm-svn: 241134
|
|
|
|
|
|
|
|
| |
using a string map to canonicalize. Fix up a couple of testcases
that needed changing since we are no longer simply appending features
to the list, but all of their mask dependencies as well.
llvm-svn: 241129
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
| |
llvm-svn: 240110
|
|
|
|
|
|
|
|
|
|
|
| |
findDominatingStoreToReturnValue.
If llvm.lifetime.end turns out to be the first instruction in the last
basic block, we can decrement the iterator twice, going past rend.
At the moment, this can never happen because llvm.lifetime.end always
goes immediately after bitcast, but relying on this is very brittle.
llvm-svn: 239638
|
|
|
|
|
|
|
|
|
|
| |
Right now we're ignoring the fpmath attribute since there's no
backend support for a feature like this and to do so would require
checking the validity of the strings and doing general subtarget
feature parsing of valid and invalid features with the target
attribute feature.
llvm-svn: 239582
|
|
|
|
|
|
|
| |
-mno- with a -<feature> to match how we handle this in the rest
of the frontend.
llvm-svn: 239581
|
|
|
|
|
|
|
| |
We don't currently support the -mtune option in any useful way
so ignoring the annotation is fine.
llvm-svn: 239580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modeled after the gcc attribute of the same name, this feature
allows source level annotations to correspond to backend code
generation. In llvm particular parlance, this allows the adding
of subtarget features and changing the cpu for a particular function
based on source level hints.
This has been added into the existing support for function level
attributes without particular verification for any target outside
of whether or not the backend will support the features/cpu given
(similar to section, etc).
llvm-svn: 239579
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds back the code that seems to have been dropped unintentionally
in r176985.
rdar://problem/13752163
Differential Revision: http://reviews.llvm.org/D10100
llvm-svn: 239426
|
|
|
|
|
|
|
|
|
|
| |
unused result detection)
This patch fixes issues with unused result detection which were found in patch http://reviews.llvm.org/D9743.
Differential Revision: http://reviews.llvm.org/D10042
llvm-svn: 239294
|
|
|
|
|
|
|
|
|
|
| |
as memcpy, memset, memmove, and bzero.
Reviewed by: Richard Smith
Differential Revision: http://reviews.llvm.org/D9673
llvm-svn: 238657
|
|
|
|
|
|
|
|
| |
Re-land the change r238200, but with modifications in the tests that should
prevent new failures in some environments as reported with the original
change on the mailing list.
llvm-svn: 238253
|
|
|
|
|
|
| |
mips-unsigned-ext-var.c and mips-unsigned-extend.c fail in some builds.
llvm-svn: 238237
|
|
|
|
|
|
|
|
|
|
| |
On MIPS unsigned int type should not be zero extended but sign-extended.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D9198
llvm-svn: 238200
|
|
|
|
|
|
| |
ArrayRef/initializer_list+braced init
llvm-svn: 237625
|
|
|
|
|
|
| |
It broke clang stage2, at least tblgen.
llvm-svn: 237418
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Space on stack allocated for unused structures returned by functions was unused
even when it's lifetime didn't intersect with lifetime of any other objects that
could use the same space.
The test added also checks for named and auto objects. It seems to make sense
to have this all in one place.
Reviewers: aadg, rsmith, rjmccall, rnk
Reviewed By: rnk
Subscribers: asl, cfe-commits
Differential Revision: http://reviews.llvm.org/D9743
llvm-svn: 237385
|
|
|
|
| |
llvm-svn: 236298
|
|
|
|
|
|
|
|
| |
This makes sure that the front end is specific about what they're expecting
the backend to produce. Update a FIXME with the idea that the target-features
could be more precise using backend knowledge.
llvm-svn: 235936
|
|
|
|
|
|
|
| |
Member pointers in the MS ABI have different alignment depending on
whether they were created on the stack or live in a record.
llvm-svn: 235681
|
|
|
|
|
|
|
|
| |
This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.
llvm-svn: 235553
|
|
|
|
|
|
|
| |
If the revert helps, I'll get a repro this Monday. Else I'll put the change
back in.
llvm-svn: 234700
|
|
|
|
| |
llvm-svn: 234600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.
llvm-svn: 234581
|
|
|
|
|
|
| |
(sorry, keep forgetting that)
llvm-svn: 234129
|
|
|
|
|
|
|
| |
Looks like the VTable code in particular will need some work to pass
around the pointee type explicitly.
llvm-svn: 234128
|
|
|
|
| |
llvm-svn: 234109
|
|
|
|
|
|
|
| |
Not all of them (there's still a fallback for this specific function
that omits the type parameter) but it's some I bothered to do now.
llvm-svn: 234063
|
|
|
|
|
|
|
| |
Use the new API for `DebugLoc` added in r233573 before the old one
disappears.
llvm-svn: 233589
|
|
|
|
|
|
|
| |
As a note, any target that uses fake target features via command
line options will have similar problems.
llvm-svn: 233227
|
|
|
|
|
|
|
| |
This breaks CodeGen for an internal target. I'll get repro instructions
to you.
llvm-svn: 232930
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the target-cpu, if different from the triple's cpu, and
target-features as they're written that are passed down from the
driver.
Together with LLVM r232885 this should allow the LTO'ing of binaries
that contain modules compiled with different code generation options
on a subset of architectures with full backend support (x86, powerpc,
aarch64).
llvm-svn: 232888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for copy-constructor closures. These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.
Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.
Differential Revision: http://reviews.llvm.org/D8225
llvm-svn: 231952
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231739
|
|
|
|
|
|
| |
Same functionality, but hoists the vector growth out of the loop.
llvm-svn: 229508
|
|
|
|
|
|
| |
We don't need a bool to track this now that we have a stack for it.
llvm-svn: 228982
|
|
|
|
|
|
|
| |
LLVM doesn't support non-call exceptions, so inlining makes it harder to
catch such asynchronous exceptions.
llvm-svn: 228876
|
|
|
|
|
|
|
| |
Disabling exceptions applies nounwind to lots of functions. SEH catches
asynch exceptions, so emit the landing pad anyway.
llvm-svn: 228769
|