| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
With IsLateTemplateParsed, FunctionDecl::doesThisDeclarationHaveABody() returns True regardless of Body.
llvm-svn: 208985
|
| |
|
|
| |
llvm-svn: 208984
|
| |
|
|
|
|
|
| |
This is part of the fix for pr10367. A GlobalAlias always has a pointer type,
so just have the constructor build the type.
llvm-svn: 208983
|
| |
|
|
| |
llvm-svn: 208982
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3707
llvm-svn: 208981
|
| |
|
|
|
|
|
|
| |
llvm::sys::path.
http://reviews.llvm.org/D3687
llvm-svn: 208980
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Updated the help message, updated description of -checks=, removed
mentions of -disable-checks.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3793
llvm-svn: 208979
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r208934.
The patch depends on aliases to GEPs with non zero offsets. That is not
supported and fairly broken.
The good news is that GlobalAlias is being redesigned and will have support
for offsets, so this patch should be a nice match for it.
llvm-svn: 208978
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3718
llvm-svn: 208977
|
| |
|
|
|
|
|
|
|
|
| |
Patch replaces old isEquivalentGEP implementation, and changes type of
comparison result from bool (equal or not) to {-1, 0, 1} (less, equal, greater).
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
llvm-svn: 208976
|
| |
|
|
| |
llvm-svn: 208975
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3691
llvm-svn: 208974
|
| |
|
|
|
|
|
|
|
|
| |
Patch replaces old isEquivalentOperation implementation, and changes type of
comparison result from bool (equal or not) to {-1, 0, 1} (less, equal, greater).
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
llvm-svn: 208973
|
| |
|
|
|
|
|
|
|
|
| |
- Tested with Eclipse, likely to work with other GDB/MI compatible GUIs.
- Some but not all MI commands have been implemented. See MIReadme.txt for more info.
- Written from scratch, no GPL code, based on LLDB Public API.
- Built for Linux, Windows and OSX. Tested on Linux and Windows.
- GDB/MI Command Reference, https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html
llvm-svn: 208972
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3788
llvm-svn: 208971
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3750
llvm-svn: 208970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TableGen has a fairly dubious heuristic to decide whether an alias should be
printed: does the alias have lest operands than the real instruction. This is
bad enough (particularly with no way to override it), but it should at least be
calculated consistently for both strings.
This patch implements that logic: first get the *correct* string for the
variant, in the same way as the Matcher, without guessing; then count the
number of whitespace chars.
There are basically 4 changes this brings about after the previous
commits; all of these appear to be good, so I have changed the tests:
+ ARM64: we print "neg X, Y" instead of "sub X, xzr, Y".
+ ARM64: we skip implicit "uxtx" and "uxtw" modifiers.
+ Sparc: we print "mov A, B" instead of "or %g0, A, B".
+ Sparc: we print "fcmpX A, B" instead of "fcmpX %fcc0, A, B"
llvm-svn: 208969
|
| |
|
|
|
|
|
|
|
| |
The canonical syntax is "fcmXY ..., #0.0".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208968
|
| |
|
|
|
|
|
|
|
|
| |
This alias appears not to have an appropriate PrintMethod. Normally, I'd look
into it, but since AArch64 is disappearing soon it's probably not worth it.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208967
|
| |
|
|
|
|
|
|
|
|
| |
These aliases are handled entirely in C++ and only having TableGen InstAliases
for some of them was confusing LLVM.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208966
|
| |
|
|
|
|
|
| |
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208965
|
| |
|
|
|
|
|
|
|
|
| |
Certainly not without having a custom PrintMethod to invert the immediate
beforehand. But probably not at all.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208964
|
| |
|
|
|
|
|
|
|
|
|
| |
In AT&T syntax, we should probably print the full "movl" or "movw". TableGen
used to ignore these aliases because it was miscounting the number of operands.
This fixes the issue.
This will be tested when the TableGen "should I print this Alias"
heuristic is fixed (very soon).
llvm-svn: 208963
|
| |
|
|
|
|
|
|
|
|
| |
Actually, MOV sometimes is canonical, but for now this is a better
approximation than what's there.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208962
|
| |
|
|
|
|
|
|
|
|
| |
You can perform (say) an fcmle operation by swapping the operands on an fcmge,
but it shouldn't be printed like that.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208961
|
| |
|
|
|
|
|
|
|
|
| |
We accept "ldr w3, [x1, #-1]" as a convenience, but we should still print the
canonical "ldur" form.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208960
|
| |
|
|
|
|
|
|
|
|
| |
If an ANDS instruction has Rd == ZR it should be printed as TST since
its only effect is on the flags register NZCV.
This will be tested when the TableGen "should I print this Alias"
heuristic is fixed (very soon).
llvm-svn: 208959
|
| |
|
|
|
|
|
|
|
| |
MOV is almost always the right thing to print if possile. People understand it.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208958
|
| |
|
|
|
|
|
|
|
|
| |
For example, the full instruction "sub w0, wzr, w1, uxtw" could print as either
"neg w0, w1" or "sub w0, wzr, w1". The former is better.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208957
|
| |
|
|
|
|
|
|
|
|
| |
You can write "lslv w0, w1, w2" (probably for legacy reasons), but it should be
printed as simply "lsl".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208956
|
| |
|
|
| |
llvm-svn: 208955
|
| |
|
|
|
| |
Review: http://reviews.llvm.org/D3688
llvm-svn: 208954
|
| |
|
|
|
|
|
| |
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
llvm-svn: 208953
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3727
llvm-svn: 208952
|
| |
|
|
| |
llvm-svn: 208951
|
| |
|
|
|
|
| |
Reformat assembly.h with clang-format. NFC.
llvm-svn: 208950
|
| |
|
|
|
|
|
|
| |
Add some Windows on ARM specific library calls. These are provided by msvcrt,
and can be used to perform integer to floating-point conversions (and
vice-versa) mirroring similar functions in the RTABI.
llvm-svn: 208949
|
| |
|
|
|
|
|
|
| |
If `-shared` is specified, pull in a PIC-version of the profile runtime,
which was added to compiler-rt in r208947. I'm hoping this will get the
bots on my side.
llvm-svn: 208948
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These tests were XPASS-ing on Linux bots creating Mach-O, which makes
sense, since the real difference is the object format.
I'm hoping a short-term fix to get these tests passing on ELF is to
create two copies of the runtime -- one built with -fPIC, and one
without. A follow-up patch will change clang's driver to pick between
them depending on whether `-shared` is specified.
llvm-svn: 208947
|
| |
|
|
|
|
|
|
|
|
|
|
| |
According to the buildbots, the new features for shared objects don't
work on ELF since it requires an -fPIC when building the profile
library. XFAIL these tests for now.
It's possible we'll have to build two versions of the profile library on
Linux (one with -fPIC and one without), but it's not clear to me exactly
how to resolve this.
llvm-svn: 208946
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.
This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.
Once the client receives the call back it can suspend the thread safely and
resume it at another time.
Related to <rdar://problem/16728690>
llvm-svn: 208945
|
| |
|
|
|
|
|
| |
declaration merging in modules is unable to find them and we get bogus errors
and even crashes.
llvm-svn: 208944
|
| |
|
|
| |
llvm-svn: 208943
|
| |
|
|
|
|
|
|
|
|
|
| |
r207606 changed the __need_foo macros to behave like they do with gcc: If they
are set, _only_ the __need_foo stuff gets defined. As a consequence, cstddef
no longer defined "offsetof". It looks like the __need_foo defines aren't
needed anymore, so just remove them.
Fixes PR19723.
llvm-svn: 208942
|
| |
|
|
|
|
| |
I missed one in r206443.
llvm-svn: 208941
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the API of the instrumented profiling library to work with shared
objects.
- Most things are now declared hidden, so that each executable gets
its own copy.
- Initialization hooks up a linked list of writers.
- The raw format with shared objects that are profiled consists of a
concatenated series of profiles. llvm-profdata knows how to deal
with that since r208938.
<rdar://problem/16918688>
llvm-svn: 208940
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Shared objects are fairly broken for InstrProf right now -- a follow-up
commit in compiler-rt will fix the rest of this.
The main problem here is that at link time, profile data symbols in the
shared object might get used instead of symbols from the main
executable, creating invalid profile data sections.
<rdar://problem/16918688>
llvm-svn: 208939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow multiple raw profiles to coexist in a single .profraw file,
given the following conditions:
- Zero padding at the end of or between profiles will be skipped.
- Each profile must start with a valid header.
- Mixing endianness or pointer sizes in concatenated profiles files is
not allowed.
This is needed to handle cases where a program's shared libraries are
profiled as well as the main executable itself, as we'll need to emit
each executable's counters. Combining the tables in the runtime would
be expensive for the instrumented program.
rdar://16918688
llvm-svn: 208938
|
| |
|
|
| |
llvm-svn: 208937
|
| |
|
|
|
|
|
| |
it's not used, because CodeGenModule::EmitGlobal consults
ASTContext::DeclMustBeEmitted via CodeGenModule::MayDeferGeneration.
llvm-svn: 208936
|