Fix infinite loop when recording conditions by correctly marking basic
blocks as visited.

Fixes https://bugs.llvm.org/show_bug.cgi?id=36105

llvm-svn: 323515

load instruction

The function `Thumb1InstrInfo::loadRegFromStackSlot` accepts only the `tGPR`
register class. The function serves to emit a `tLDRspi` instruction and
certainly any subset of the `tGPR` register class is a valid destination of the
load.

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

llvm-svn: 323514

Reviewers: andrew.w.kaylor, craig.topper, MatzeB

Reviewed By: andrew.w.kaylor

Subscribers: aivchenk, llvm-commits

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

llvm-svn: 323513

This is the groundwork for Armv8.2-A FP16 code generation .

Clang passes and returns _Float16 values as floats, together with the required
bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318.
We will implement half-precision argument passing/returning lowering in the ARM
backend soon, but for now this means that this:

_Float16 sub(_Float16 a, _Float16 b) {
  return a + b;
}

gets lowered to this:

define float @sub(float %a.coerce, float %b.coerce) {
entry:
  %0 = bitcast float %a.coerce to i32
  %tmp.0.extract.trunc = trunc i32 %0 to i16
  %1 = bitcast i16 %tmp.0.extract.trunc to half
  <SNIP>
  %add = fadd half %1, %3
  <SNIP>
}

When FullFP16 is *not* supported, we don't make f16 a legal type, and we get
legalization for "free", i.e. nothing changes and everything works as before.
And also f16 argument passing/returning is handled.

When FullFP16 is supported, we do make f16 a legal type, and have 2 places that
we need to patch up: f16 argument passing and returning, which involves minor
tweaks to avoid unnecessary code generation for some bitcasts.

As a "demonstrator" that this works for the different FP16, FullFP16, softfp
modes, etc., I've added match rules to the VSUB instruction description showing
that we can codegen this instruction from IR, but more importantly, also to
some conversion instructions. These conversions were causing issue before in
the FP16 and FullFP16 cases.

I've also added match rules to the VLDRH and VSTRH desriptions, so that we can
actually compile the entire half-precision sub code example above. This showed
that these loads and stores had the wrong addressing mode specified: AddrMode5
instead of AddrMode5FP16, which turned out not be implemented at all, so that
has also been added.

This is the minimal patch that shows all the different moving parts. In patch
2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the
remaining Armv8.2-A FP16 instruction descriptions.


Thanks to Sam Parker and Oliver Stannard for their help and reviews!


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

llvm-svn: 323512

Summary:
This is probably the right behavior for distributed tracers, and makes unpaired
begin-end events impossible without requiring Spans to be bound to a thread.

The API is conceptually clean but syntactically awkward. As discussed offline,
this is basically a naming problem and will go away if (when) we use TLS to
store the current context.

The apparently-unrelated change to onScopeExit are because its move semantics
broken if Func is POD-like since r322838. This is true of function pointers,
and the lambda I use here that captures two pointers only.
I've raised this issue on llvm-dev and will revert this part if we fix it in
some other way.

Reviewers: ilya-biryukov

Subscribers: klimek, jkorous-apple, ioeric, cfe-commits

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

llvm-svn: 323511

"in in" -> "in", "on on" -> "on" etc.

llvm-svn: 323510

"in in" -> "in", "on on" -> "on" etc.

llvm-svn: 323509

"in in" -> "in", "on on" -> "on" etc.

llvm-svn: 323508

llvm-svn: 323507

Type legalization would prevent any i64 operands to the build_vector from existing before we get here. The coverage bots show this code as uncovered.

llvm-svn: 323506

It likely the number of elements in the type we're legalizing here is reasonably small.

llvm-svn: 323505

[X86] Remove code from combineBitcastvxi1 that was needed to support the previous native IR for kunpck intrinsics.

The original autoupgrade for kunpck intrinsics used a bitcasted scalar shift, or, and. This combine would turn this into a concat_vectors. Now the kunpck intrinsics are autoupgraded to a vector shuffle that will become a concat_vectors.

llvm-svn: 323504

llvm-svn: 323503

This listed all legal 128-bit integer types individually, but since we already know we have a legal type and its integer, we can just check is128BitVector.

llvm-svn: 323502

These kinds of setccs are promoted by a DAG combine before they ever get to legalization.

llvm-svn: 323501

This code was added in r321967, but ultimately I fixed the issue in the legalizer and this code was no longer required.

llvm-svn: 323500

Otherwise, a shared library build with SJLJ APIs enabled would
end up with duplicate symbols.

This didn't occur for the apple && arm case due to specifically
checking for that in the surrounding ifdef.

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

llvm-svn: 323499

Switch Select handling on after fixing two bugs: rL323192 and rL323497.

llvm-svn: 323498

When pass creates a MOV instruction for 
lea (%base,%index,1), %dst => mov %base,%dst; add %index,%dst
modification it should clean the killed flag for base
if base is equal to index.

Otherwise verifier complains about usage of killed register in add instruction.

Reviewers: lsaba, zvi, zansari, aaboud
Reviewed By: lsaba
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42522

llvm-svn: 323497

Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.

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

llvm-svn: 323496

[cmake] [libcxxabi] Call llvm_setup_rpath() when adding shared libraries.

Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.

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

llvm-svn: 323495

Somehow I reverted changes I made in a previous Reland. This change re-relands
unconfusing a varible name with a type name.

llvm-svn: 323494

I had more unused varibles. This change removes those to get rid of warnings.

llvm-svn: 323493

Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.

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

llvm-svn: 323492

We need to use the vcruntime declarations on Windows to avoid an
ODR violation involving rtti.obj, which provides the definition of
the runtime function implementing dynamic_cast and depends on the
vcruntime implementations of bad_cast and bad_typeid.

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

llvm-svn: 323491

Code on Windows expects to be able to do:

 #define _USE_MATH_DEFINES
 #include <math.h>

and receive the definitions of mathematical constants, even if <math.h>
has previously been included. To support this scenario, re-include
<math.h> every time the wrapper header is included.

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

llvm-svn: 323490

Added line to output the proper files in the output to binary case.

llvm-svn: 323489

A test for option /foo is usually named foo.test, but this test
file is not for the /order option, so rename it to avoid confusion.

llvm-svn: 323488

llvm-svn: 323487

Tests were working on my system because the old correct files were left over
and the new bug was that the output files were not being output at all.
Consequently the test work on my system but fail on any other system.

This reverts commit r323484.

llvm-svn: 323486

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

llvm-svn: 323485

I named a varible the same as a type which caused a warning. I also had unamed varibles.

llvm-svn: 323484

Similar to the existing handling for internal symbols, private symbols
are also not visible to the linker and should be ignored.

llvm-svn: 323483

Inserting a dbg.value instruction at the start of a basic block with a
landingpad instruction triggers a verifier failure. We should be OK if
we insert the instruction a bit later.

Speculative fix for the bot failure described here:
https://reviews.llvm.org/D42551

llvm-svn: 323482

Move standard forms from a switch statement to the table of forms;
fill in all the missing ones defined in DWARF v5.  I'm guessing at
classifications in a couple of cases where v5 forms aren't actually
supported yet, but whoever adds support for the forms can fix the
classifications as needed.

llvm-svn: 323481

While writing code for input and output formats in llvm-objcopy it became
apparent that there was a code health problem. This change attempts to solve
that problem by refactoring the code to use Reader and Writer objects that can
read in different objects in different formats, convert them to a single shared
internal representation, and then write them to any other representation.

New classes:
Reader: the base class used to construct instances of the internal
representation
Writer: the base class used to write out instances of the internal
representation
ELFBuilder: a helper class for ELFWriter that takes an ELFFile and converts it
to a Object
SectionVisitor: it became necessary to remove writeSection from SectionBase
because, under the new Reader/Writer scheme, it's possible to convert between
ELF Types such as ELF32LE and ELF32BE. This isn't possible with writeSection
because it (dynamically) depends on the underlying section type *and*
(statically) depends on the ELF type. Bad things would happen if the underlying
sections for ELF32LE were used for writing to ELF64BE. To avoid this code smell
(which would have compiled, run, and output some nonsesnse) I decoupled writing
of sections from a class.
SectionWriter: This is just the ELFT templated implementation of
SectionVisitor. Many classes now have this class as a friend so that the
writing methods in this class can write out private data.
ELFWriter: This is the Writer that outputs to ELF
BinaryWriter: This is the Writer that outputs to Binary
ElfType: Because the ELF Type is not a part of the Object anymore we need a way
to construct the correct default Writer based on properties of the Reader. This
enum just keeps track of the ELF type of the input so it can be used as the
default output type as well.

Object has correspondingly undergone some serious changes as well. It now has
more generic methods for building and manipulating ELF binaries. This interface
makes ELFBuilder easy enough to use and will make the BinaryReader/Builder easy
to create as well. Most changes in this diff are cosmetic and deal with the
fact that a method has been moved from one class to another or a change from a
pointer to a reference. Almost no changes should result in a functional
difference (this is after all a refactor). One minor functional change was made
and the result can be seen in remove-shstrtab-error.test. The fact that it
fails hasn't changed but the error message has changed because that failure is
detected at a later point in the code now (because WriteSectionHeaders is a
property of the ElfWriter *not* a property of the Object). I'd say roughly
80-90% of this code is cosmetically different, 10-19% is different but
functionally the same, and 1-5% is functionally different despite not causing a
change in tests.

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

llvm-svn: 323480

llvm-svn: 323479

llvm-svn: 323478

This change adds support for --add-gnu-debuglink to llvm-objcopy

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

llvm-svn: 323477

This form is like DW_FORM_strp, but points to .debug_line_str instead
of .debug_str as the string section.  It's intended to be used from
the line-table header, and allows string-pooling of directory and
filenames across compilation units.

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

llvm-svn: 323476