We were fairly inconsistent as to what information should be accessed
with getSectionHdr and what information (like alignment) was stored
elsewhere.

Now all section info has a dedicated getter. The code is also a bit
more compact.

llvm-svn: 285079

llvm-svn: 285078

It is not safe to use LOAD ON CONDITION to implement access to a memory
location marked "volatile", since the architecture leaves it unspecified
whether or not an access happens if the condition is false.

The current code already appears to care about that:
  def LOC  : CondUnaryRSY<"loc",  0xEBF2, nonvolatile_load, GR32, 4>;

Unfortunately, that "nonvolatile_load" operator is simply ignored
by the CondUnaryRSY class, and there was no test to catch it.

llvm-svn: 285077

Disable the OpenSUSE rules for OpenSUSE versions older than 11 as they
are incompatible with the old binutils on that distribution.

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

llvm-svn: 285076

llvm-svn: 285075

Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.

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

llvm-svn: 285074

This allows for the coalescing of the protocol declarations.  When the protocols
are declared in headers, multiple definitions of the protocol would be emitted.
Marking them as common data indicates that any one can be selected.

llvm-svn: 285073

We already have (V)PMOVZX* combining support, this is the beginning of handling (V)PMOVSX* similarly - other combines in combineVSZext can be generalized in future patches.

This unearthed an interesting bug in that we were generating illegal build vectors on 32-bit targets - it was proving difficult to create a test for it from PMOVZX, but it fired immediately with PMOVSX. I've created a more general form of the existing getConstVector to handle these cases - ideally this should be handled in non-target-specific code but I couldn't find an equivalent.

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

llvm-svn: 285072

When adding an llvm.memcpy instruction to AliasSetTracker, it uses the raw
source and target pointers which preserve bitcasts.
MemAccInst::getPointerOperand() also returns the raw target pointers, but
Scop::buildAliasGroups() did not for the source pointer. This lead to mismatches
between AliasSetTracker and ScopInfo on which pointer to use.

Fixed by also using raw pointers in Scop::buildAliasGroups().

llvm-svn: 285071

Accidentally put in the hoped-for checks ahead of the transform!

llvm-svn: 285070

llvm-svn: 285069

This reverts commit r284828, as it causes an infinite loop in
TestPrintStackTraces (funnily enough, only when logging is enabled).

llvm-svn: 285068

LLVM_ATTRIBUTE_UNUSED doesn't work for non-gcc style compilers.

llvm-svn: 285067

llvm-svn: 285066

Patch by Sam McCall, test case by me.

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

llvm-svn: 285065

llvm-svn: 285064

Summary:
Do *not* perform combines such as:

    vector_shuffle<4,1,2,3>(build_vector(Ud, C0, C1 C2), scalar_to_vector(X))
    ->
    build_vector(X, C0, C1, C2)

Keeping the shuffle allows lowering the constant build_vector to a materialized
constant vector (such as a vector-load from the constant-pool or some other idiom).

Reviewers: delena, igorb, spatel, mkuper, andreadb, RKSimon

Subscribers: llvm-commits

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

llvm-svn: 285063

llvm-svn: 285062

In an IR symbol table I would expect the comdats to be represented as:

- A table of strings, one for each comdat name.
- Each symbol has an optional index into that table.

The natural api for accessing that would be

InputFile:
ArrayRef<StringRef> getComdatTable() const;

Symbol:
int getComdatIndex() const;

This patch implements an API as close to that as possible.  The
implementation on top of the current IRObjectFile is a bit hackish,
but should map just fine over a symbol table and is very convenient to
use.

llvm-svn: 285061

Raise a signal if the buffer has been modified before replacing it, to
avoid overwriting users' changes.

Patch by Philipp Stephani.

llvm-svn: 285060

Patch by Philipp Stephani.

llvm-svn: 285059

For the purpose of highlighting in an IDE.

llvm-svn: 285057

Warnings generated by -Wdocumentation-unknown-command did only have a
start location, not a full source range. This resulted in only the
"carret" being show in messages, and IDEs highlighting only the single
initial character.

llvm-svn: 285056

Patch by Sam McCall!

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

llvm-svn: 285055

[X86][AVX512][Clang][Intrinsics][reduce] Adding missing reduce (Operators: +,*,&&,||) intrinsics to Clang
 
Committed after LGTM and check-all

 
Vector-reduction arithmetic accepts vectors as inputs and produces scalars as outputs.
This class of vector operation forms the basis of many scientific computations.
In vector-reduction arithmetic, the evaluation off is independent of the order of the input elements of V.
 
Used bisection method. At each step, we partition the vector with previous
step in half, and the operation is performed on its two halves.
This takes log2(n) steps where n is the number of elements in the vector.
 
Reviwer: 1. igorb
         2. craig.topper    
Differential Revision: https://reviews.llvm.org/D25527

llvm-svn: 285054

[AVX-512] Add support for creating SIGN_EXTEND_VECTOR_INREG and ZERO_EXTEND_VECTOR_INREG for 512-bit vectors to support vpmovzxbq and vpmovsxbq.

Summary: The one tricky thing about this is that the sign/zero_extend_inreg uses v64i8 as an input type which isn't legal without BWI support. Though the vpmovsxbq and vpmovzxbq instructions themselves don't require BWI. To support this we need to add custom lowering for ZERO_EXTEND_VECTOR_INREG with v64i8 input. This can mostly reuse the existing sign extend code with a couple checks for sign extend vs zero extend added.

Reviewers: delena, RKSimon

Subscribers: llvm-commits

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

llvm-svn: 285053

llvm-svn: 285052

This is a function to go backwards in a block to find the first
instruction in a bundle, so iterator is a more natural choice for
parameter/return rather than a reference to a MachineInstruction.

llvm-svn: 285051

llvm-svn: 285050

llvm-svn: 285049

llvm-svn: 285048

Returning `false` was stopping the parsing of further arguments,
which wasn't intended.

llvm-svn: 285047

llvm-svn: 285046

llvm-svn: 285045

The p2align operand of a load/store is encoded before the offset
operand; reorder the MachineInstr operands accordingly.

llvm-svn: 285044

When we load coverage data from multiple objects, we don't have a way to
attribute a source object to a function record. Printing out the object
filename next to the source filename is already not very useful: soon,
it'll actually become misleading. Stop printing out the filename now.

llvm-svn: 285043

This is unbreaking the build with shared library after r285019.

llvm-svn: 285042

Unadvertently removed in r285019

llvm-svn: 285041

This changes locals from being declared by the emitLocal hook in
WebAssemblyTargetStreamer, rather than with an instruction. After exploring
the infastructure in LLVM more, this seems to make more sense since
declaring locals doesn't use an encoded opcode.

This also adds more 0xd opcodes, type encodings, and miscellaneous
binary encoding bits.

llvm-svn: 285040

Passing a MachineFunction as argument is more natural and avoids an
unnecessary round-trip through the logic determining the correct
Subtarget because MachineFunction already has a reference anyway.

llvm-svn: 285039