Move all metadata construction into AMDGPUHSAMetadataStreamer.

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

llvm-svn: 336707

Fix building GCDAProfiling.c with pre-C99 compilers.
This caused a build bot failure.

llvm-svn: 336706

Processors before z14 don't support non-execute protection,
so they will start execution random memory contents, causing
the test to randomly fail or succeed.

llvm-svn: 336705

This fix add more test cases for routines check MIPS ELF header flags and
flags from .MIPS.abiflags sections. The tests use yaml2obj for object
files generation because not all combinations of flags can be produced
by LLVM tools.

llvm-svn: 336704

The instruction selection is automatically handled by tablegen

llvm-svn: 336703

This fixes PR38120

llvm-svn: 336702

udiv x,-1 was going down the (slow) BuildUDIV route resulting in unnecessary shifts.

llvm-svn: 336701

llvm-svn: 336700

It turns out that the `${XRAY_HEADERS}` CMake variable was already
in use and was used for public headers. It seems that
`lib/xray/tests/CMakeLists.txt` was depending on this.

To fix rename the new `${XRAY_HEADERS}` to `${XRAY_IMPL_HEADERS}`.

llvm-svn: 336699

This reverts r336529 because an alternative approach turned out to be a
better fit for dsymuil.

llvm-svn: 336698

amdgpu-implicitarg-num-bytes attribute

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

llvm-svn: 336697

This corresponds with the code for the single binop pattern
added in rL336684.

llvm-svn: 336696

llvm-svn: 336695

Match the tests in combine-sdiv.ll

llvm-svn: 336694

Two fixes required to handle big-endian systems:

- 64-bit counter values are stored in a mixed-endian format in the
gcov files: a 32-bit low-part followed by a 32-bit high part. Note that
this is already implemented correctly on the LLVM side, see
GCOVBuffer::readInt64.

- The tag values (e.g. arcs tag, object summary tag, ...) are aways
written as the same sequence of bytes independent of byte order. But
when *reading* them back in, the code reads them as 32-bit values in
host byte order. For the comparisons to work correctly, this should
instead always read them as little-endian values.

Fixes PR 38121.

Reviewed By: marco-c

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

llvm-svn: 336693

The llvm_gcov_... routines in compiler-rt are regular C functions that
need to be called using the proper C ABI for the target. The current
code simply calls them using plain LLVM IR types. Since the type are
mostly simple, this happens to just work on certain targets. But other
targets still need special handling; in particular, it may be necessary
to sign- or zero-extended sub-word values to comply with the ABI. This
caused gcov failures on SystemZ in particular.

Now the very same problem was already fixed for the llvm_profile_ calls
here: https://reviews.llvm.org/D21736

This patch uses the same method to fix the llvm_gcov_ calls, in
particular calls to llvm_gcda_start_file, llvm_gcda_emit_function, and
llvm_gcda_emit_arcs.

Reviewed By: marco-c

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

llvm-svn: 336692

llvm-svn: 336691

llvm-svn: 336690

hsa-metadata-enqueu-kernel.ll ->
hsa-metadata-enqueue-kernel.ll

llvm-svn: 336689

When manually finishing the object writer in dsymutil, it's possible
that there are pending labels that haven't been resolved. This results
in an assertion when the assembler tries to fixup a label that doesn't
have an address yet.

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

llvm-svn: 336688

llvm-svn: 336687

llvm-svn: 336686

is useful to omit the debug compilation dir when compiling assembly
files with -g.  Part of PR38050.

Patch by Siddhartha Bagaria!

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

llvm-svn: 336685

This was originally intended with D48893, but as discussed there, we
have to make the folds safe from producing extra poison. This should
give the single binop folds the same capabilities as the existing
folds for 2-binops+shuffle.

LLVM binary opcode review: there are a total of 18 binops. There are 7 
commutative binops (add, mul, and, or, xor, fadd, fmul) which we already 
fold. We're able to fold 6 more opcodes with this patch (shl, lshr, ashr,
fdiv, udiv, sdiv). There are no folds for srem/urem/frem AFAIK. We don't 
bother with sub/fsub with constant operand 1 because those are 
canonicalized to add/fadd. 7 + 6 + 3 + 2 = 18.

llvm-svn: 336684

This accessor is useful and could be slightly more efficient than
Str.val().data() because you can avoid StringRef instantiation.

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

llvm-svn: 336683

If a machine function satisfies SSA, the IsSSA property is assumed even
if the pass to be executed runs after existing from SSA. If the pass
output then does not conform to SSA, a verifier error will be flagged
(with expensive checks enabled).

llvm-svn: 336682

llvm-svn: 336681

debug compilation dir when compiling assembly files with -g.
Part of PR38050.

Patch by Siddhartha Bagaria!

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

llvm-svn: 336680

llvm-svn: 336679

This reapplies r336365, after marking tests as failing on various
configurations.

llvm-svn: 336678

This patch adds support for the following instructions:
  CLS  (Count Leading Sign bits)
  CLZ  (Count Leading Zeros)
  CNT  (Count non-zero bits)
  CNOT (Logically invert boolean condition in vector)
  NOT  (Bitwise invert vector)
  FABS (Floating-point absolute value)
  FNEG (Floating-point negate)

All operations are predicated and unary, e.g.
  clz  z0.s, p0/m, z1.s

- CLS, CLZ, CNT, CNOT and NOT have variants for 8, 16, 32
  and 64 bit elements.

- FABS and FNEG have variants for 16, 32 and 64 bit elements.

llvm-svn: 336677

llvm-svn: 336676

This reverts commit r336623

llvm-svn: 336675

llvm-svn: 336674

llvm-svn: 336673

.gdb_index sections can be very large. When you are compiling
multi-gibibyte executables, they can be larger than 1 GiB. The previous
implementation of .gdb_index seems to consume too much memory.

This patch reduces memory consumption by eliminating temporary objects.
In one experiment, memory consumption of GdbIndexSection class is
reduced from 962 MiB to 228 MiB when creating a .gdb_index of 1350 GiB.

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

llvm-svn: 336672

Summary:
This adds an option, max-symbol-complexity, so an user can set the maximum symbol complexity threshold.

Note that the current behaviour is equivalent to max complexity = 0, when taint analysis is not enabled and tests show that in a number of tests, having complexity = 25 yields the same results as complexity = 10000.

This patch was extracted and modified from Dominic Chen's patch, D35450.

Reviewers: george.karpenkov, NoQ, ddcc

Reviewed By: george.karpenkov

Subscribers: xazax.hun, szepet, a.sidorin

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

llvm-svn: 336671

This is to test the following untested line:
https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L643

llvm-svn: 336670

not supported on Darwin currently and so Clang refuses to compile with
`-fsanitize=memory`.

llvm-svn: 336669

The case with 2 variables is more complicated than the case where
we eliminate the shuffle entirely because a shuffle with an undef 
mask element creates an undef result. 

I'm not aware of any current analysis/transform that recognizes that 
undef propagating to a div/rem/shift, but we have to guard against 
the possibility.

llvm-svn: 336668