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

Summary:
This will fix some bugs where navigation doesn't work on cases like
`std::cout <^< "hello"`.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373323

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

Summary:
If the file heuristic fails, we try to use the index&AST to do the
header/source inference.

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373320

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

llvm-svn: 373319

Reviewers: kadircet

Reviewed By: kadircet

Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373318

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

NFC preparation work for upcoming ExternalASTMerger patches.

llvm-svn: 373312

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

And move the relevant information in the doc.

Summary:
Currently, building a large software like Firefox shows
'Use chrome://tracing or Speedscope App (https://www.speedscope.app) for flamegraph visualization'
for each file.

Reviewers: anton-afanasyev

Reviewed By: anton-afanasyev

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 373308

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: nridge, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373305

Summary: When creating the module, must have copy-pasted from the misc module, and forgotten to update the name/description of the module in the registry.

Reviewers: stephanemoore, benhamilton, gribozavr

Reviewed By: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang, #clang-tools-extra, #llvm

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

llvm-svn: 373304

[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

Summary: This patch adds support of watchpoints to the new `NativeProcessWindows` plugin. The same tests as in D67168 pass with these changes when the old plugin is turned off, so they will cover this functionality when the old plugin is gone.

Reviewers: asmith, amccarth, stella.stamenova, labath

Reviewed By: labath

Subscribers: labath, jfb, JDevlieghere, lldb-commits, leonid.mashinskiy

Tags: #lldb

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

llvm-svn: 373300

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

variable with non-trivial destruction.

We still need to invoke the thread wrapper to trigger registration of
the destructor call on thread shutdown.

llvm-svn: 373289

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

Summary:
File::Clear() is an ugly function.  It's only used in one place,
which is the swig typemaps for FILE*.   This patch refactors and
renames that function to make it clear what it's really for and
why nobody else should use it.

Both File::TakeStreamAndClear() and the FILE* typemaps will be
removed in later patches after a suitable replacement is in place.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 373285

Summary: Fixes https://github.com/google/oss-fuzz/issues/2836

Reviewers: eugenis

Subscribers: dberris, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 373284