This reverts commit rL373317 due to test failure on the
clang-s390x-linux build bot.

llvm-svn: 373336

Seems to be slower than memcpy + strlen.

llvm-svn: 373335

llvm-svn: 373333

Otherwise, shared-lib build fails with:

lib64/libLLVMExegesis.a(SnippetFile.cpp.o): In function `llvm::exegesis::readSnippets(llvm::exegesis::LLVMState const&, llvm::StringRef)':
SnippetFile.cpp:(.text._ZN4llvm8exegesis12readSnippetsERKNS0_9LLVMStateENS_9StringRefE+0x31f): undefined reference to `llvm::createMCAsmParser(llvm::SourceMgr&, llvm::MCContext&, llvm::MCStreamer&, llvm::MCAsmInfo const&, unsigned int)'
SnippetFile.cpp:(.text._ZN4llvm8exegesis12readSnippetsERKNS0_9LLVMStateENS_9StringRefE+0x41c): undefined reference to `llvm::MCAsmParser::setTargetParser(llvm::MCTargetAsmParser&)'
collect2: error: ld returned 1 exit status

llvm-svn: 373332

Add some tail predication tests with fast math.

llvm-svn: 373331

DIExpression::createFragmentExpression - silence static analyzer DIExpression* null dereference warning with an assertion. NFCI.

llvm-svn: 373326

Silences a number of clang static analyzer null dereference warnings.

llvm-svn: 373325

ObjectFile makeTriple - silence static analyzer dyn_cast<COFFObjectFile> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<COFFObjectFile> directly and if not assert will fire for us.

llvm-svn: 373324

The static analyzer is warning about a potential null dereference, as we're already earlying-out for a null Constant pointer I've just folded this into a dyn_cast_or_null<ConstantInt>.

No test case, this is by inspection only.

llvm-svn: 373322

Goes a bit further than rL372743 which added the early out - elements should be Constant so use cast<Constant> instead (and rely on the assert if anything fails).

llvm-svn: 373321

The success return value for data extractor's cursor
should also be checked.

llvm-svn: 373319

The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

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

llvm-svn: 373317

This allows setting any sh_link values for SHT_HASH sections.

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

llvm-svn: 373316

SHT_HASH specification is:
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#hash

In short the format is the following: it has 2 uint32 fields
in its header: nbucket and nchain followed by (nbucket + nchain)
uint32 values.

This patch allows dumping and parsing such sections.

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

llvm-svn: 373315

...since it's using an x86 triple.

llvm-svn: 373314

Reviewers: gchatelet, a.sidorin

Subscribers: tschuett, llvm-commits

Tags: #llvm

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

llvm-svn: 373313

This reverts commit r373299. It broke tests:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/18485

llvm-svn: 373311

This reverts commit r373294. It broke Clang's
CodeGen/arm64-microsoft-status-reg.cpp:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/18483

llvm-svn: 373310

llvm-svn: 373309

[X86] Consider isCodeGenOnly in the EVEX2VEX pass to make VMAXPD/PS map to the non-commutable VEX instruction. Use EVEX2VEX override to fix the scalar instructions.

Previously the match was ambiguous and VMAXPS/PD and VMAXCPS/PD
were mapped to the same VEX instruction. But we should keep
the commutableness when change the opcode.

llvm-svn: 373303

Summary:
In CFGSort, we try to make EH pads have higher priorities as soon as
they are ready to be sorted, to prevent creation of unwind destination
mismatches in CFGStackify. We did that by making priority queues'
comparison function  prefer EH pads, but it was possible for an EH pad
to be popped from `Preferred` queue and then not sorted immediately and
enter `Ready` queue instead in a certain condition. This patch makes
sure that special condition does not consider EH pads as its candidates.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

llvm-svn: 373302

Summary:
Fixing unwind mismatches for exception handling can result in splicing
existing BBs and moving some of instructions to new BBs. In this case
some of stackified def registers in the original BB can be used in the
split BB. For example, we have this BB and suppose %r0 is a stackified
register.
```
bb.1:
  %r0 = call @foo
  ... use %r0 ...
```

After fixing unwind mismatches in CFGStackify, `bb.1` can be split and
some instructions can be moved to a newly created BB:
```
bb.1:
  %r0 = call @foo

bb.split (new):
  ... use %r0 ...
```

In this case we should make %r0 un-stackified, because its use is now in
another BB.

When spliting a BB, this CL unstackifies all def registers that have
uses in the new split BB.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

llvm-svn: 373301

LLVMGetInitializer returns nullptr in case there is no
initializer. There is not much that can be done with nullptr in OCaml,
not even test if it is null. Also, there does not seem to be a C or
OCaml API to test if there is an initializer. So this diff changes
Llvm.global_initializer to return an option.

Differential Revision: https://reviews.llvm.org/D65195
Reviewed by: whitequark
Authored by: kren1

llvm-svn: 373299

llvm-svn: 373298

llvm-svn: 373297

TThe existing wave32 behavior seems broken and incomplete, but this
reproduces it.

llvm-svn: 373296

llvm-svn: 373295

SelectionDAG has a bunch of machinery to defer this to selection time
for some reason. Just directly emit a copy during IRTranslator. The
x86 usage does somewhat questionably check hasFP, which could depend
on the whole function being at minimum translated.

This does lose the convergent bit if the callsite had it, which may be
a problem. We also lose that in general for intrinsics, which may also
be a problem.

llvm-svn: 373294

This is sort of papering over the fact that we don't run a combiner
anywhere, but avoiding creating 2 instructions in the first place is
easy.

llvm-svn: 373293

Replace with the MachineFunction. X86 is the only user, and only uses
it for the function. This removes one obstacle from using this in
GlobalISel. The other is the more tolerable EVT argument.

The X86 use of the function seems questionable to me. It checks hasFP,
before frame lowering.

llvm-svn: 373292

D68110 added --arch-specific (supported by GNU readelf) and made
--arm-attributes an alias for it. The tests were later migrated to use
--arch-specific.

Note, llvm-readelf --arch-specific currently just uses llvm-readobj
style output for ARM attributes. The readelf-style output is not
implemented.

Reviewed By: compnerd, kongyi, rupprecht

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

llvm-svn: 373291

[X86] Add test case to show missed opportunity to shrink a constant index to a gather in order to avoid splitting.

Also add a test case for an index that could be shrunk, but
would create a narrow type. We can go ahead and do it we just
need to be before type legalization.

Similar test cases for scatter as well.

llvm-svn: 373290

llvm-svn: 373288

Legalize 16-bit G_SITOFP/G_UITOFP for AMDGPU.

llvm-svn: 373287

Handle other cases besides LDS. Mostly a straight port of the existing
handling, without the intermediate custom nodes.

llvm-svn: 373286

llvm-svn: 373278

This patch fixes the build break on Windows hosts.

There must be a better way of accessing the equivalent POSIX math constant
`M_E`.

llvm-svn: 373274

llvm-svn: 373273

llvm-svn: 373271

llvm-svn: 373269