This reverts r369486 (git commit 8d183848)

The opt-viewer tests don't pass after this change, and fixing them isn't
trivial. opt-viewer.py imports optmap, which requires adjusting
pythonpath, which is more work than I'm willing to do to fix forward.

llvm-svn: 370095

Summary:
@eugenis to approve addition of //compiler-rt/tools.
@pree-jackie please confirm that this WFY.

D66494 introduced the GWP-ASan stack_trace_compressor_fuzzer. Building fuzz
targets in compiler-rt is a new affair, and has some challenges:
- If the host compiler doesn't have compiler-rt, the -fsanitize=fuzzer may not
  be able to link against `libclang_rt.fuzzer*`.
- Things in compiler-rt generally aren't built when you want to build with
  sanitizers using `-DLLVM_USE_SANITIZER`. This tricky to work around, so
  we create the new tools directory so that we can build fuzz targets with
  sanitizers. This has the added bonus of fixing the problem above as well, as
  we can now just guard the fuzz target build to only be done with
  `-DLLVM_USE_SANITIZE_COVERAGE=On`.

Reviewers: eugenis, pree-jackie

Reviewed By: eugenis, pree-jackie

Subscribers: dberris, mgorny, #sanitizers, llvm-commits, eugenis, pree-jackie, lebedev.ri, vitalybuka, morehouse

Tags: #sanitizers, #llvm

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

llvm-svn: 370094

triple in addition to -darwin

The previous check incorrectly checked for macOS support by
allowing -darwin triples only, and -macos triple was not supported.

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

llvm-svn: 370093

Summary:
This patch introduces, SequenceBBQuery - new heuristic to find likely next callable functions it tries to find the blocks with calls in order of execution sequence of Blocks.

It still uses BlockFrequencyAnalysis to find high frequency blocks. For a handful of hottest blocks (plan to customize), the algorithm traverse and discovered the caller blocks along the way to Entry Basic Block and Exit Basic Block. It uses Block Hint, to stop traversing the already visited blocks in both direction. It implicitly assumes that once the block is visited during discovering entry or exit nodes, revisiting them again does not add much. It also branch probability info (cached result) to traverse only hot edges (planned to customize) from hot blocks. Without BPI, the algorithm mostly return's all the blocks in the CFG with calls.

It also changes the heuristic queries, so they don't maintain states. Hence it is safe to call from multiple threads.

It also implements, new instrumentation to avoid jumping into JIT on every call to the function with the help _orc_speculate.decision.block and _orc_speculate.block.

"Speculator Registration Mechanism is also changed" - kudos to @lhames

Open to review, mostly looking to change implementation of SequeceBBQuery heuristics with good data structure choices.

Reviewers: lhames, dblaikie

Reviewed By: lhames

Subscribers: mgorny, hiraditya, mgrang, llvm-commits, lhames

Tags: #speculative_compilation_in_orc, #llvm

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

llvm-svn: 370092

Before this patch, users were not allowed to optionally mark processor resource
groups as load/store queues. That is because tablegen class MemoryQueue was
originally declared as expecting a ProcResource template argument (instead of a
more generic ProcResourceKind).

That was an oversight, since the original intention from D54957 was to let user
mark any processor resource as either load/store queue.  This patch adds the
ability to use processor resource groups in MemoryQueue definitions. This is not
a user visible change.

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

llvm-svn: 370091

The results port was used by dosep.py to deal with test results coming
form different processes. With dosep.py gone, I don't think we need this
any longer.

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

llvm-svn: 370090

llvm-svn: 370089

llvm-svn: 370088

-fms-extensions is intended to enable conforming language extensions and
-fms-compatibility is intended to language rule relaxations, so a user
could plausibly compile with -fno-ms-compatibility on Windows while
still using dllexport, for example.  This exception specification
validation behavior has been handled as a warning since before
-fms-compatibility was added in 2011. I think it's just an oversight
that it hasn't been moved yet.

This will help users find conformance issues in their code such as those
found in _com_ptr_t as described in https://llvm.org/PR42842.

Reviewers: hans

Subscribers: STL_MSFT, cfe-commits

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

llvm-svn: 370087

This is something of a workaround since computeRegisterProperties
seems to be doing the wrong thing.

llvm-svn: 370086

Summary: CFGWalk Query is unimplemented for valid reasons. But the declaration got included in commit file.

Reviewers: lhames, dblaikie

Reviewed By: dblaikie

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 370085

I thought `llvm::sort` was stable for some reason but it's not.

Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`.

Original patch: https://reviews.llvm.org/D66498

llvm-svn: 370084

32 bit unsigned, and 64 bit pointers.

llvm-svn: 370083

This fixes the issue where a filename dependendency was missing if the file that
was referenced with __has_include() was accessed through a symlink in an earlier run,
if the file manager was reused between runs.

llvm-svn: 370081

When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get
stable output.

Reverting while I debug it.

See: https://reviews.llvm.org/D66498
llvm-svn: 370080

[X86] Remove encoding information from the TAILJMP instructions that are lowered by MCInstLowering. Fix LowerPATCHABLE_TAIL_CALL to also convert them to regular JMP/JCC instructions

There are 5 instructions here that are converted from TAILJMP opcodes to regular JMP/JCC opcodes during MCInstLowering. So normally there encoding information isn't used. The exception being when XRay wraps them in PATCHABLE_TAIL_CALL.

For the ones that weren't already handled in MCInstLowering, add handling for those and remove their encoding information.

This patch fixes PATCHABLE_TAIL_CALL to do the same opcode conversion as the regular lowering patch. Then removes the encoding information.

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

llvm-svn: 370079

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

Patch by Leonid Mashinskiy

llvm-svn: 370078

The timers track time spent loading objects, linking, and (if applicable)
running JIT-link'd code.

llvm-svn: 370075

On MachO, processing of the eh-frame section should stop if the end of the
__eh_frame section is reached, regardless of whether or not there is a null CFI
length field at the end of the section. This patch tracks the eh-frame section
size and threads it through the appropriate APIs so that processing can be
terminated correctly.

No testcase yet: This patch is all API plumbing (rather than modification of
linked memory) which the existing infrastructure does not provide a way of
testing. Committing without a testcase until I have an idea of how to write
one.

llvm-svn: 370074

Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called.

Reviewers: jfb, jyknight, wmi, asb

Reviewed By: asb

Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits

Tags: #clang

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

llvm-svn: 370073

If content sections have lower alignment than zero-fill sections then bump the
overall segment alignment to avoid under-aligning the zero-fill sections.

llvm-svn: 370072

(-X) * (-Y) + Z --> X * Y + Z

This is a missing optimization that shows up as a potential regression in D66050,
so we should solve it first. We appear to be partly missing this fold in IR as well.

We do handle the simpler case already:
(-X) * (-Y) --> X * Y

And it might be beneficial to make the constraint less conservative (eg, if both
operands are cheap, but not necessarily cheaper), but that causes infinite looping
for the existing fmul transform.

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

llvm-svn: 370071

Summary:
Adds support for emitting common local global symbols to an XCOFF object file.
Local commons are emitted into the .bss section with a storage class of
C_HIDEXT.

Patch by: daltenty

Reviewers: sfertile, hubert.reinterpretcast

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

llvm-svn: 370070

This reverts commit b3d258fc.

@skatkov is reporting crash in D63972#1646303
Contacted @ZhangKang, and revert the commit on behalf of him.

llvm-svn: 370069

This updates the SARIF exporter to produce SARIF 2.1 output. The bulk of the diffs come from two changes to SARIF:
* https://github.com/oasis-tcs/sarif-spec/issues/309
* https://github.com/oasis-tcs/sarif-spec/issues/179

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

llvm-svn: 370068

ClampScalar G_SHL, G_ASHR and G_LSHR to s32 for MIPS32.

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

llvm-svn: 370067

llvm-svn: 370066

Main difference is in the way Hi for Long shift (HiL) is made.
G_LSHR fills HiL with zeros, while G_ASHR fills HiL with sign bit value.

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

llvm-svn: 370064

Fix typos. Use Hi and Lo prefixes for Or instead of LHS and RHS
to match names of surrounding variables.

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

llvm-svn: 370062

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

llvm-svn: 370061

According to the SARIF specification, "a text region does not include the character specified by endColumn".

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

llvm-svn: 370060

llvm-svn: 370059

llvm-svn: 370058

llvm-svn: 370057

Summary: As per title.

Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 370056

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

llvm-svn: 370055

pexpect gives as raw data going to a terminal. This means that if the
completed line does not fit the emulated line, the returned data will
contain line breaks. On my machine these line breaks happened to be
inside the "iohandler/completion" string that the test was searching
for.

Work around this by telling pexpect to emulate a very wide terminal.

llvm-svn: 370054

Summary:
This patch adds support for scalable vectors in intrinsics, enabling
intrinsics such as the following to be defined:

    declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>)

Support for this is implemented by defining a new type descriptor for
scalable vectors and adding mangling support for scalable vector types
in the name mangling scheme used by 'any' types in intrinsic signatures.

Tests have been added for IRBuilder to test scalable vectors work as
expected when using intrinsics through this interface. This required
implementing an intrinsic that is explicitly defined with scalable
vectors, e.g.  LLVMType<nxv4i32>, an SVE floating-point convert
intrinsic was used for this.  The behaviour of the overloaded type
LLVMScalarOrSameVectorWidth with scalable vectors is tested using the
existing masked load intrinsic. Also added an .ll test to test the
Verifier catches a bad intrinsic argument when passing a fixed-width
predicate (mask) to the masked.load intrinsic where a scalable is
expected.

Patch by Paul Walker

Reviewed By: sdesmalen

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

llvm-svn: 370053

Currently, clang accepts a union with a reference member when given the -fms-extensions flag. This change fixes the codegen for this case.

Patch by Dominic Ferreira.

llvm-svn: 370052

llvm-svn: 370051