In rare cases we can receive request to inject into completelly empty basic block. In the normal case 
all basic blocks contain at least terminator instruction, but it is possible that the only instruction is 
catchpad instruction which is not part of the instruction iterator. This case seems rare enough to not care
about it.
Submiting without review, since it seems almost NFC. I couldn't come up with any reasonable way to test this.

llvm-svn: 319444

The test is about failing to hit breakpoints in global constructors in
shared libraries.

llvm-svn: 319443

Differential Revision: https://reviews.llvm.org/D40397

llvm-svn: 319442

Differential Revision: https://reviews.llvm.org/D40396

llvm-svn: 319441

Differential Revision: https://reviews.llvm.org/D40395

llvm-svn: 319440

Differential Revision: https://reviews.llvm.org/D40394

llvm-svn: 319439

Differential Revision: https://reviews.llvm.org/D40393

llvm-svn: 319438

As noted in D40594, the frem instruction corresponds to fmod() except that it can't set errno.
I modified the text that we currently use for intrinsics that map to libm functions and applied
it to frem.

Differential Revision: https://reviews.llvm.org/D40629

llvm-svn: 319437

llvm-svn: 319436

Since MarkLive.cpp is the place where we set Live flags for
other sections, it looks correct to do that there.
Benefit is that we stop spreading GC logic outsize of MarkLive.cpp.

Differential revision: https://reviews.llvm.org/D40454

llvm-svn: 319435

This re-commits everything that was pulled in r314244. The transformation
is off by default (patch to enable it to follow). The code is refactored
to have a single entry-point and provide fine-grained control over patterns
that it selects. This patch also fixes the bugs in the original code.

Everything that failed with the original patch has been re-tested with this
patch (with the transformation turned on). So the patch to turn this on is
soon to follow.

Differential Revision: https://reviews.llvm.org/D38575

llvm-svn: 319434

llvm-svn: 319433

llvm-svn: 319432

Summary:
This can be seen as a follow-up on my previous differential [D33411](https://reviews.llvm.org/D33411).
We received a bug report where this error was triggered. I have tried my best to recreate the issue in a minimal lit testcase which is also part of this differential.

I only handle return instructions as predecessors to a virtual TLR-exit right now. From inspecting the codebase, it seems `unreachable` instructions may also be of interest here. If requested, I can extend my patches to consider them as well. I would also apply this on `ScopHelper.cpp::isErrorBlock` (see D33411), of course.

Reviewers: philip.pfaffe, bollu

Reviewed By: bollu

Subscribers: Meinersbur, pollydev, llvm-commits

Tags: #polly

Differential Revision: https://reviews.llvm.org/D40492

llvm-svn: 319431

Re applying after fixing issues in the diff, sorry for any painful conflicts/merges!

Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html

This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).

The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary.

There is a follow up change to add an option to clang.

Thanks.

Reviewers: hfinkel, MatzeB

Reviewed By: MatzeB

Subscribers: thegameg, asb, llvm-commits

Differential Revision: https://reviews.llvm.org/D39788

llvm-svn: 319430

I messed up the diff.

llvm-svn: 319429

Fallback if we have a byval parameter or argument since we don't support
them yet.

llvm-svn: 319428

As part of the unification of the debug format and the MIR format, avoid
printing "vreg" for virtual registers (which is one of the current MIR
possibilities).

Basically:

* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/%vreg([0-9]+)/%\1/g"
* grep -nr '%vreg' . and fix if needed
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/ vreg([0-9]+)/ %\1/g"
* grep -nr 'vreg[0-9]\+' . and fix if needed

Differential Revision: https://reviews.llvm.org/D40420

llvm-svn: 319427

In r319314 clang-format changed its reflowing logic.

llvm-svn: 319426

This reverts r319420
It is failing the test Driver/arm-mfpu.c so reverting while I investigate the failure.

llvm-svn: 319425

llvm-svn: 319424

Summary:
Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html

I wasn't sure who to put as reviewers, so please add/remove people as appropriate.

This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).

The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary.

There is a follow up change to add an option to clang.

Thanks.

Reviewers: hfinkel, MatzeB

Reviewed By: MatzeB

Subscribers: thegameg, asb, llvm-commits

Differential Revision: https://reviews.llvm.org/D39788

llvm-svn: 319423

Patch by Olga Malysheva

Differential Revision: https://reviews.llvm.org/D40309

llvm-svn: 319422

visitAND attempts to narrow the width of extending loads that are
then masked off. ReduceLoadWidth already exists for a similar purpose
and handles shifts, so I've moved the code to handle AND nodes there.

Differential Revision: https://reviews.llvm.org/D39595

llvm-svn: 319421

To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,

  -mfloat-abi=soft -fpu=neon

If any floating point features which require FPU hardware are enabled
they must be disable.

There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).

Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.

Differential Revision: https://reviews.llvm.org/D40256

llvm-svn: 319420

llvm-svn: 319419

llvm-svn: 319418

Should fix build failure introduced by r319416 on non-darwin hosts.

llvm-svn: 319417

This patch implements `getBundleInfo`, which uses CoreFoundation to
obtain information about the CFBundle. This information is needed to
populate the Plist in the dSYM bundle.

This change only applies to darwin and is an NFC as far as other
platforms are concerned.

Differential revision: https://reviews.llvm.org/D40244

llvm-svn: 319416

Summary:
Otherwise automatic semicolon insertion can trigger, i.e. wrapping
produces invalid syntax.

Reviewers: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D40642

llvm-svn: 319415

Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.

Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.

Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D40615

llvm-svn: 319414

The basic idea behind this patch is that since in strict aliasing
mode all accesses to union members require their outermost
enclosing union objects to be specified explicitly, then for a
couple given accesses to union members of the form

p->a.b.c...
q->x.y.z...

it is known they can only alias if both p and q point to the same
union type and offset ranges of members a.b.c... and x.y.z...
overlap. Note that the actual types of the members do not matter.

Specifically, in this patch we do the following:

* Make unions to be valid TBAA base access types. This enables
  generation of TBAA type descriptors for unions.

* Encode union types as structures with a single member of a
  special "union member" type. Currently we do not encode
  information about sizes of types, but conceptually such union
  members are considered to be of the size of the whole union.

* Encode accesses to direct and indirect union members, including
  member arrays, as accesses to these special members. All
  accesses to members of a union thus get the same offset, which
  is the offset of the union they are part of. This means the
  existing LLVM TBAA machinery is able to handle such accesses
  with no changes.

While this is already an improvement comparing to the current
situation, that is, representing all union accesses as may-alias
ones, there are further changes planned to complete the support
for unions. One of them is storing information about access sizes
so we can distinct accesses to non-overlapping union members,
including accesses to different elements of member arrays.
Another change is encoding type sizes in order to make it
possible to compute offsets within constant-indexed array
elements. These enhancements will be addressed with separate
patches.

Differential Revision: https://reviews.llvm.org/D39455

llvm-svn: 319413

...at least when building against glibc-2.26-16.fc27.x86_64

llvm-svn: 319412

Summary:
Currently clang static analyzer does warn on:
```
int x;
x+=1;
x-=1;
x=x+1;
x=x-1;
```
But does warn on:
```
int x;
x++;
x--;
--x;
++x;
```

This differential should fix that.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35419

Reviewers: dcoughlin, NoQ

Reviewed By: dcoughlin

Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin

Tags: #clang

Differential Revision: https://reviews.llvm.org/D40463

llvm-svn: 319411

This reverts commit rL319407 due to failures in some buildbot.

llvm-svn: 319410

Csmith generated a program where a store after load to the same address did
not get chained after the new load created during DAG legalizing, and so
performed an illegal overwrite of the expected value.

When the new zero-extending load is created, the chain users of the original
load must be updated, which was not done previously.

A similar case was also found and handled in lowerBITCAST.

Review: Ulrich Weigand
https://reviews.llvm.org/D40542

llvm-svn: 319409

Sometimes we check the validity of some construct between producing a
diagnostic and producing its notes. Ideally, we wouldn't do that, but in
practice running code that "cannot possibly produce a diagnostic" in such a
situation should be safe, and reasonable factoring of some code requires it
with our current diagnostics infrastruture. If this does happen, a diagnostic
that's suppressed due to SFINAE should not cause notes connected to the prior
diagnostic to be suppressed.

llvm-svn: 319408

Currently, SROA splits loads and stores only when they are accessing the whole alloca.
This patch relaxes this limitation to allow splitting a load/store if all other loads and stores to the alloca are disjoint to or fully included in the current load/store. If there is no other load or store that crosses the boundary of the current load/store, the current splitting implementation works as is.
The whole-alloca loads and stores meet this new condition and so they are still splittable.

Here is a simplified motivating example.

struct record {
    long long a;
    int b;
    int c;
};

int func(struct record r) {
    for (int i = 0; i < r.c; i++)
        r.b++;
    return r.b;
}

When updating r.b (or r.c as well), LLVM generates redundant instructions on some platforms (such as x86_64, ppc64); here, r.b and r.c are packed into one 64-bit GPR when the struct is passed as a method argument.

With this patch, the above example is compiled into only few instructions without loop.
Without the patch, unnecessary loop-carried dependency is introduced by SROA and the loop cannot be eliminated by the later optimizers.

Differential Revision: https://reviews.llvm.org/D32998

llvm-svn: 319407

Normal type legalization will widen everything. This requires forcing 0s into the mask register. We can instead choose the form that only reads 2 elements without zeroing the mask.

llvm-svn: 319406

We don't use k-registers and instead use the MSB so we need to make sure we sign extend the mask to the msb.

llvm-svn: 319405