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

llvm-svn: 363345

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

llvm-svn: 363344

This reverts commit 6e6e3af5.

This breaks greendragon.

llvm-svn: 363343

It looks like an older version of gcc can't figure out that it needs to
move a unique_ptr while implicitly constructing an Expected object.

llvm-svn: 363342

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

llvm-svn: 363341

In addition to being unused and duplicating code, this was also wrong
(it didn't properly mark the operand as being potentially not odr-used).

llvm-svn: 363340

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

llvm-svn: 363339

llvm-svn: 363338

nullptr_t does not access memory.

We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.

This reinstates r345562, reverted in r346065, now that CodeGen's
handling of non-odr-used variables has been fixed.

llvm-svn: 363337

Summary: AFAIK, the "sparc" target is big endian and the target for 32-bit little-endian SPARC is denoted as "sparcel". This patch fixes the endianness of "sparc" target and adds "sparcel" target for 32-bit little-endian SPARC.

Reviewers: espindola, alexshap, rupprecht, jhenderson

Reviewed By: jhenderson

Subscribers: jyknight, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits

Tags: #llvm

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

llvm-svn: 363336

Summary:
Before it was using the fully qualified name only for static data members.
Now it does for all variable names to match MSVC.

Reviewers: rnk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 363335

The only caller of SymbolizableObjectFile::create passes a non-null
DebugInfoContext and asserts that they do so. Move the assert into
SymbolizableObjectFile::create and remove null checks.

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

llvm-svn: 363334

gcc 4.8.4 (but not 5.4.0 or 7.3.0) has trouble initializing errc with {}, giving
the error in [1]. This CL switches to explicitly using errc(0), which gcc 4.8
accepts.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=973723

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

llvm-svn: 363333

llvm-svn: 363332

Constants, including G_GLOBAL_VALUE, are all emitted into the entry block which
lets us use the vreg def assuming it dominates all other users. However, it can
cause jumpy debug behaviour since the DebugLoc attached to these MIs are from
a user instruction that could be in a different block.

Fixes PR40887.

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

llvm-svn: 363331

[X86Disassembler] Unify the EVEX and VEX code in emitContextTable. Merge the ATTR_VEXL/ATTR_EVEXL bits. NFCI

Merging the two bits shrinks the context table from 16384 bytes to 8192 bytes.

Remove the ATTRIBUTE_BITS macro and just create an enum directly. Then fix the ATTR_max define to be 8192 to reflect the table size so we stop hardcoding it separately.

llvm-svn: 363330

This was exposed by PowerPC target enablement.

In ScheduleDAG, if we haven't seen any uses in this scheduling region,
we will create a dependence edge to ExitSU to model the live-out latency.
This is required for vreg defs with no in-region use, and prefetches with
no vreg def.

When we build NodeOrder in Scheduler, we ignore these boundary nodes.
However, when we check Succs in checkValidNodeOrder, we did not skip
them, so we still assume all the nodes have been sorted and in order in
Indices array. So when we call lower_bound() for ExitSU, it will return
Indices.end(), causing memory issues in following Node access.

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

llvm-svn: 363329

* Add a common function to setup opt-remarks
* Rename common options to the same names
* Add error types to distinguish between file errors and regex errors

llvm-svn: 363328

llvm-svn: 363327

[libFuzzer] simplify the DFT trace collection using the new faster DFSan mode that traces up to 16 labels at a time and never runs out of labels.

llvm-svn: 363326

Support loading code coverage data from regular archives, thin archives,
and from MachO universal binaries which contain archives.

Testing: check-llvm, check-profile (with {A,UB}San enabled)

rdar://51538999

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

llvm-svn: 363325

llvm-svn: 363324

It was missing from D63293 and breaks in a debug tablegen w/o
this part.

llvm-svn: 363323

notifyResolved/notifyEmitted.

The 'notify' prefix better describes what these methods do: they update the JIT
symbol states and notify any pending queries that the 'resolved' and 'emitted'
states have been reached (rather than actually performing the resolution or
emission themselves). Since new states are going to be introduced in the near
future (to track symbol registration/initialization) it's worth changing the
convention pre-emptively to avoid further confusion.

llvm-svn: 363322

Summary:
dfsan_flush() allows to restart tain tracking from scratch in the same process.
The primary purpose right now is to allow more efficient data flow tracing
for DFT fuzzing: https://github.com/google/oss-fuzz/issues/1632

Reviewers: pcc

Reviewed By: pcc

Subscribers: delcypher, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 363321

I find the current documentation of poison somewhat confusing,
mainly because its use of "undefined behavior" doesn't seem to
align with our usual interpretation (of immediate UB). Especially
the sentence "any instruction that has a dependence on a poison
value has undefined behavior" is very confusing.

Clarify poison semantics by:

 * Replacing the introductory paragraph with the standard rationale
   for having poison values.
 * Spelling out that instructions depending on poison return poison.
 * Spelling out how we go from a poison value to immediate undefined
   behavior and give the two examples we currently use in ValueTracking.
 * Spelling out that side effects depending on poison are UB.

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

llvm-svn: 363320

Also add baseline tests to show effect of later patches.

There were a couple of regressions here that were never caught,
but my patch set that this is a preparation to will fix them.

This is the third attempt to land this patch.

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

llvm-svn: 363319

I recently got this wrong (again), and I'm sure I'm not the only one.  Put a comment in the logical place someone would look to "fix" the obvious "missed optimization" which arrises based on the common misunderstanding.  Hopefully, this will save others time.  :)

llvm-svn: 363318

Revert "[NFC][CodeGen] Add unary fneg tests to fp-fast.ll fp-fold.ll fp-in-intregs.ll fp-stack-compare-cmov.ll fp-stack-compare.ll fsxor-alignment.ll"

This reverts commit 1d85a751.

llvm-svn: 363317

This reverts commit 5c011405.

llvm-svn: 363316

This reverts commit f1b8c6ac.

llvm-svn: 363315

This reverts commit 06de5267.

llvm-svn: 363314

This reverts commit f288a068.

llvm-svn: 363313

This reverts commit 3d2ee005.

llvm-svn: 363312

This reverts commit 169fc2b0.

llvm-svn: 363311

This reverts commit 66f28684.

llvm-svn: 363310

This reverts commit 4f3cf385.

llvm-svn: 363309

This reverts commit ee5881a8.

llvm-svn: 363308

This reverts commit 5f39a309.

llvm-svn: 363307

This reverts commit 10c08555.

llvm-svn: 363306