This change gives the llvm-elfabi tool the ability to read DT_SONAME from a binary ELF file into an ELFStub.

Added:

 - DynamicEntries struct for storing dynamic entries that are relevant to elfabi.
 - terminatedSubstr() retrieves a null-terminated substring from a StringRef.
 - appendToError() appends a string to an error, allowing more specific error messages.

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

llvm-svn: 351361

This test, apparently for macs, fails on Windows as lit can't emulate
the shell subprocess $(which...) correctly. Some other netbsd and linux
buildbots also fail here. Limit to macs as a temporary workaround.

llvm-svn: 351360

In this test we have deliberately removed all information which may hint
at the correct path style, so we cannot assert that lldb uses a
particular style. Instead, we should just check that it does something
vaguely reasonable.

llvm-svn: 351359

dbg.value intrinsics can appear in blocks where their operand is not used,
meaning the operand never receives an SDNode, and thus no DBG_VALUE will
be created. Get around this by looking to see whether the operand has already
been allocated a virtual register. This allows dbg.values of Phi node and
Values that are used across basic blocks to successfully be translated into
DBG_VALUEs.

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

llvm-svn: 351358

Change-Id: I8a22cb4b4bef9bceee1f43381435d664c2cfd770
llvm-svn: 351357

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

llvm-svn: 351356

llvm-svn: 351355

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

llvm-svn: 351354

This reverts commit r351330 due to failures on MacOS bots.

llvm-svn: 351353

combineX86ShufflesRecursively is pretty cumbersome with a lot of arguments that only matter later in recursion.

This commit adds a wrapper version that only takes the initial root Op to simplify calls that don't need to worry about these.

An early, cleanup step towards merging combineX86ShufflesRecursively into SimplifyDemandedVectorElts/SimplifyDemandedBits.

llvm-svn: 351352

Reviewers: arsenm, nhaehnle

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 351351

llvm-svn: 351350

Summary:
Sometimes the SLP vectorizer tries to vectorize the horizontal reduction
nodes during regular vectorization. This may happen inside of the loops,
when there are some vectorizable PHIs. Patch fixes this by checking if
the node is the reduction node and thus it must not be vectorized, it must
be gathered.

Reviewers: RKSimon, spatel, hfinkel, fedor.sergeev

Subscribers: llvm-commits

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

llvm-svn: 351349

This is useful for multiple checks.

llvm-svn: 351348

Summary:
When llvm-nm is passed only the --size-sort option for an object file, there is no output generated.
The commit modifies the behavior to print the symbols sorted and their size which is also inline with
the output of the GNU nm tool.

Signed-off-by: Saurabh Badhwar <sbsaurabhbadhwar9@gmail.com>

Reviewers: enderby, rupprecht

Reviewed By: rupprecht

Subscribers: llvm-commits

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

llvm-svn: 351347

I was trying to prevent shuffle regressions while matching more horizontal ops 
and ended up here:
  shuf (extract X, 0), (extract X, 4), Mask --> extract (shuf X, undef, Mask'), 0

The affected tests were added for:
https://bugs.llvm.org/show_bug.cgi?id=34380

This patch won't change the examples in the bug report itself, but we should be 
able to extend this to catch more types.

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

llvm-svn: 351346

This is LLVM part of D56663

Linker scripts shipped by TI require to have every
interrupt vector in a separate section with a specific name:

 SECTIONS
 {
   __interrupt_vector_XX   : { KEEP (*(__interrupt_vector_XX )) } > VECTXX
   ...
 }

Follow the requirement emit the section for every vector
which contain address of interrupt handler:

  .section  __interrupt_vector_XX,"ax",@progbits
  .word %isr%

Patch by Kristina Bessonova!

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

llvm-svn: 351345

* Accept as an argument constants in range 0..63 (aligned with TI headers and linker scripts provided with TI GCC toolchain).
* Emit function attribute 'interrupt'='xx' instead of aliases (used in the backend to create a section for particular interrupt vector).
* Add more diagnostics.

Patch by Kristina Bessonova!

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

llvm-svn: 351344

llvm-svn: 351341

Patch by Kristina Bessonova!

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

llvm-svn: 351340

As a follow on to D56666 (r351186) there is a case when taking the address
of an ifunc when linking -pie that can generate a spurious can't create
dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol in readonly
segment. Specifically the case is where the ifunc is in the same
translation unit as the address taker, so given -fpie the compiler knows
the ifunc is defined in the executable so it can use a non-got-generating
relocation.

The error message is due to R_AARCH64_PLT_PAGE_PC not being added to
isRelExpr, its non PLT equivalent R_AARCH64_PAGE_PC is already in
isRelExpr.

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

llvm-svn: 351335

To fix a buildbot failure on PS4, see
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/42251

The test was added in r351222 and aims to check only a particular
Mac configuration. However it relied on the default compiler target
by default, therefore unintentionally failing on PS4.

llvm-svn: 351334

llvm-svn: 351333

llvm-svn: 351332

This avoids the "ambiguous else" warning, which comes from within the
EXPECT_TRUE macro.

llvm-svn: 351331

Summary:
Adding a breakpad symbol file to an existing MachO module with "target symbols
add" currently works only if one's host platform is a mac. This is
because SymbolVendorMacOSX (which is the one responsible for loading
symbols for MachO files) is conditionally compiled for the mac platform.

While we will sooner or later have a special symbol vendor for breakpad
files (to enable more advanced searching), and so this flow could be
made to work through that, it's not clear to me whether this should be a
requirement for the "target symbols add" flow to work. After all, since
the user has explicitly specified the symbol file to use, the symbol
vendor plugin's job is pretty much done.

This patch teaches the default symbol vendor to respect module's symbol
file spec, and load the symbol from that file if it is specified (and no
plugin requests any special handling).

Reviewers: clayborg, zturner, lemo

Subscribers: lldb-commits

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

llvm-svn: 351330

This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.

> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 351329

Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.

The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.

This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.

This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.

Reviewers: clayborg, zturner, JDevlieghere

Subscribers: aprantl, lldb-commits

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

llvm-svn: 351328

This reverts commit r351250 because it breaks the
SymbolFile/NativePDB/function-types-builtins.cpp.

llvm-svn: 351327

By default LLD will generate position independent Thunks when the --pie or
--shared option is used. Reference to absolute addresses is permitted in
other cases. For some embedded systems position independent thunks are
needed for code that executes before the MMU has been set up. The option
--pic-veneer is used by ld.bfd to force position independent thunks.
    
The patch adds --pic-veneer as the option is needed for the Linux kernel
on Arm.
    
fixes pr39886
    
Differential Revision: https://reviews.llvm.org/D55505

llvm-svn: 351326

For the given test SROA detects possible replacement and creates a correct alloca. After that SROA is adding lifetime markers for this new alloca. The function getNewAllocaSlicePtr is trying to deduce the pointer type based on the original alloca, which is split, to use it later in lifetime intrinsic.

For the test we ended up with such code (rA is initial alloca [10 x float], which is split, and rA.sroa.0.0 is a new split allocation)

```
%rA.sroa.0.0.rA.sroa_cast = bitcast i32* %rA.sroa.0 to [10 x float]*    <----- this one causing the assertion and is an extra bitcast
%5 = bitcast [10 x float]* %rA.sroa.0.0.rA.sroa_cast to i8*
call void @llvm.lifetime.start.p0i8(i64 4, i8* %5)
```

isAllocaPromotable code assumes that a user of alloca may go into lifetime marker through bitcast but it must be the only one bitcast to i8* type. In the test it's not a i8* type, return false and throw the assertion.

As we are creating a pointer, which will be used in lifetime markers only, the proposed fix is to create a bitcast to i8* immediately to avoid extra bitcast creation.

The test is a greatly simplified to just reproduce the assertion.

Author: Igor Tsimbalist <igor.v.tsimbalist@intel.com>

Reviewers: chandlerc, craig.topper

Reviewed By: chandlerc

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

llvm-svn: 351325

As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

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

llvm-svn: 351324

The compiler warns about an unused variable/statement:

    runtime/src/kmp_affinity.cpp:4958:18: warning: statement has no effect [-Wunused-value]
       KA_TRACE(1000, ; {
                      ^
    runtime/src/kmp_debug.h:84:24: note: in definition of macro 'KA_TRACE'
         __kmp_debug_printf x;                                                      \
                            ^

Instead of the unused reference to this function, this patch now calls the function
with an empty string. The call to this function should have no effect.

Patch provided by joachim.protze

Reviewers: jlpeyton, hbae, AndreyChurbanov

Reviewed By: AndreyChurbanov

Tags: #openmp, #ompt

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

llvm-svn: 351323

Summary: To avoid adding an extern function to the global ctors list, apply the changes of D56538 also to MSan.

Reviewers: chandlerc, vitalybuka, fedor.sergeev, leonardchan

Subscribers: hiraditya, bollu, llvm-commits

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

llvm-svn: 351322

llvm-svn: 351320

The two-argument version of  llvm::sys::fs::make_absolute no longer
returns an error code.

llvm-svn: 351319

The value returned by max() is the last valid value, adjust the
comparison accordingly.

The code added in D55073 creates TokenFactors with max() operands.

Reviewers: aemerson, efriedma, RKSimon, craig.topper

Reviewed By: aemerson

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

llvm-svn: 351318

Summary:
The version of make_absolute which accepted a specific directory to use
as the "base" for the computation could never fail, even though it
returned a std::error_code. The reason for that seems to be historical
-- the CWD flavour (which can fail due to failure to retrieve CWD) was
there first, and the new version was implemented by extending that.

This removes the error return value from the non-CWD overload and
reimplements the CWD version on top of that. This enables us to remove
some dead code where people were pessimistically trying to handle the
errors returned from this function.

Reviewers: zturner, sammccall

Subscribers: hiraditya, kristina, llvm-commits

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

llvm-svn: 351317

Reapply [Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database.

This reverts commit r351282, and re-lands r351222 and r351229 with the
use-after-free fixed.

llvm-svn: 351316

llvm-svn: 351315