The function with uwtable attribute might be visited by the
stack unwinder, thus the link register should be considered
as clobbered after the execution of the branch and link
instruction (i.e. the definition of the machine instruction
can't be ignored) even when the callee function are marked
with noreturn.

llvm-svn: 202165

Summary:
Contains a short user's manual and some instructions on writing
clang-tidy checks.

Reviewers: klimek, djasper

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2880

llvm-svn: 202164

The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:

* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
  function can have a dramatic knock on effect. If the size of the function
  changes it might change the alignment and therefore the performance of
  all the functions that happen to follow it in the binary. This butterfly
  effect makes it harder to reason about and measure the performance of
  code.

llvm-svn: 202163

llvm-svn: 202162

Mark LWG Issues 2278 and 2313 as complete. No code changes needed; libc++ already implemented both of these.

llvm-svn: 202161

llvm-svn: 202158

llvm-svn: 202157

llvm-svn: 202156

llvm-svn: 202155

  Don't actually Halt in the Interrupt handler for the Process, just
  send an AsyncInterrupt.  That's actually not async-signal-clean, but
  it is a lot safer than Halt...

The underlying problem is actually a nested pthread_cond_wait from the
signal handler.  Note frames 4, 13, 18 in the backtrace of the aborting
path below.

    frame #1: 0x000000080715fff9 libc.so.7`abort + 73 at abort.c:65
    frame #2: 0x0000000805d20fda libthr.so.3`_thread_exit(fname=<unavailable>, lineno=<unavailable>, msg=<unavailable>) + 58 at thr_exit.c:182
    frame #3: 0x0000000805d1fdc8 libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 936 at thr_cond.c:223
    frame #4: 0x0000000805d1fd5b libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 827 at thr_cond.c:311
    frame #5: 0x00000008013450b5 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 117
    frame #6: 0x00000008013411e8 liblldb.so.3.5`lldb_private::Predicate<bool>::WaitForValueEqualTo(bool, lldb_private::TimeValue const*, bool*) + 200
    frame #7: 0x00000008013eb34c liblldb.so.3.5`lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::__1::shared_ptr<lldb_private::Event>&) + 876
    frame #8: 0x00000008013eb751 liblldb.so.3.5`lldb_private::Listener::WaitForEvent(lldb_private::TimeValue const*, std::__1::shared_ptr<lldb_private::Event>&) + 81
    frame #9: 0x00000008017c5bcf liblldb.so.3.5`lldb_private::Process::Halt(bool) + 783
    frame #10: 0x00000008017def3a liblldb.so.3.5`IOHandlerProcessSTDIO::Interrupt() + 74
    frame #11: 0x00000008013823d3 liblldb.so.3.5`lldb_private::Debugger::DispatchInputInterrupt() + 115
    frame #12: 0x00000008011d69c5 liblldb.so.3.5`lldb::SBDebugger::DispatchInputInterrupt() + 69
    frame #13: 0x000000000040b254 lldb`sigint_handler(int) + 68
    frame #14: 0x0000000805d1b3da libthr.so.3`handle_signal(actp=<unavailable>, sig=<unavailable>, info=<unavailable>, ucp=<unavailable>) + 234 at thr_sig.c:240
    frame #15: 0x0000000805d1afc2 libthr.so.3`thr_sighandler(sig=<unavailable>, info=<unavailable>, _ucp=<unavailable>) + 306 at thr_sig.c:183
    frame #16: 0x00007ffffffff003
    frame #17: 0x0000000805d1fc7e libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=1) + 239 at thr_cond.c:255
    frame #18: 0x0000000805d1fb8f libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) + 367 at thr_cond.c:311
    frame #19: 0x00000008013450d2 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 146

llvm-svn: 202154

llvm-svn: 202153

The 'f' modifier is designed for integer type arguments really (according to
its documentation). It's better to use the "half width, same number" modifier.

Should be no user-visible change.

llvm-svn: 202152

llvm-svn: 202151

Partially based on http://llvm-reviews.chandlerc.com/D2644 by Viktor Kutuzov.

llvm-svn: 202150

waitid() is present since API level 9 (Android 2.3). That's old enough.

llvm-svn: 202149

llvm-svn: 202148

Also assert that we never create non-array string literals again.

PR18939.

llvm-svn: 202147

RewriteObjC: Factor string literal creation into a helper and make sure it gets a proper constant array type.

No change in output.

llvm-svn: 202146

* Fix bash scripts to work on FreeBSD (patch by Viktor Kutuzov)
* Update locations of lit tests in check_lint script.

llvm-svn: 202145

This should fix the issues with `make check-asan` on OS X.

llvm-svn: 202144

llvm-svn: 202143

llvm-svn: 202142

llvm-svn: 202141

just "load". This helps avoid pointless de-duping with order-sensitive
numbers as we already have unique names from the original load. It also
makes the resulting IR quite a bit easier to read.

llvm-svn: 202140

the pointer adjustment code. This is the primary code path that creates
totally new instructions in SROA and being able to lump them based on
the pointer value's name for which they were created causes
*significantly* fewer name collisions and general noise in the debug
output. This is particularly significant because it is making it much
harder to track down instability in the output of SROA, as name
de-duplication is a totally harmless form of instability that gets in
the way of seeing real problems.

The new fancy naming scheme tries to dig out the root "pre-SROA" name
for pointer values and associate that all the way through the pointer
formation instructions. Digging out the root is important to prevent the
multiple iterative rounds of SROA from just layering too much cruft on
top of cruft here. We already track the layers of SROAs iteration in the
alloca name prefix. We don't need to duplicate it here.

Should have no functionality change, and shouldn't have any really
measurable impact on NDEBUG builds, as most of the complex logic is
debug-only.

llvm-svn: 202139

These seem to be supported by GCC, and do make sense architecturally so we
should probably have them.

llvm-svn: 202138

llvm-svn: 202137

PHI-pointer builder, just copy the builder and clobber the obvious
fields.

llvm-svn: 202136

using OldPtr more heavily. Lots of this code was written before the
rewriter had an OldPtr member setup ahead of time. There are already
asserts in place that should ensure this doesn't change any
functionality.

llvm-svn: 202135

llvm-svn: 202134

This comment survived the transition from ForceInline to InlineAlways,
fix it.

llvm-svn: 202133

llvm-svn: 202132

The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.

This preserves the semantics of the previous implementation but with
less duplication of code.

llvm-svn: 202131

llvm-svn: 202130

the break statement, not just think it to yourself....

No idea how this worked at all, much less survived most bots, my
bootstrap, and some bot bootstraps!

The Polly one didn't survive, and this was filed as PR18959. I don't
have a reduced test case and honestly I'm not seeing the need. What we
probably need here are better asserts / debug-build behavior in
SmallPtrSet so that this madness doesn't make it so far.

llvm-svn: 202129

llvm-svn: 202128

llvm-svn: 202127

llvm-svn: 202126

llvm-svn: 202125

[asan] Fix for size_t in Asan's new and delete operators on x64 FreeBSD in 32-bit mode, only for FreeBSD <= 9.2; patch by Viktor Kutuzov

llvm-svn: 202124