machine-outliner-mapping-stats.mir

[RISCV] Don't use constantpool for floating-point value if the value can be easily constructed by integer sequence and a floating-point move.

In addition, this commit does the following combine

vfmv.v.f + fmv.[dhw].x -> vmv.v.x
vfmv.s.f + fmv.[dhw].x -> vmv.s.x
vfmerge.vfm + fmv.[dhw].x -> vmerge.vxm

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

Add a test for statistics as well.

The mapper size stats were nested in a loop unnecessarily. Move them out.

Give existing stats better names, and add one which also tracks the number of
sentinels added.

Unused in the wild.

Adding debug output to improve outliner debuggability + testability.

Move `nooutline` attribute test into the new debug output test.

This reverts commit c7b1176e.

This reverts commit 62570b72.

`os.mkfifo` may not be supported everywhere (e.g. windows).

Supporting 3.6 requires a bit too much of a change in the mlgo test python scripts.

GCC on AArch64 uses DW_CFA_GNU_NegateRAState for return address signing.

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

Reviewed By: MaskRay

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

The fix only affects Darwin, but to write the test I had to modify
the MemoryMappingLayout class which is used by all OSes,
to allow for mocking of image header (this change should be NFC). Hence no [Darwin] in the subject
so I can get more eyes on it.

While looking for a memory gap to put the shadow area into, the sanitizer code
scans through the loaded images, and for each image it scans through its
loader command to determine the occupied memory ranges.

While doing so, if the 'segment load' (kLCSegment) loader comand is encountered, the command scanning function
returns success (true), but does not decrement the command list iterator counter.
The result is that the function is called again and again, with the iterator counter
now being too high. The command scanner keeps updating the loader command pointer,
by using the command size field.

If the loop counter is too high, the command pointer
lands into unintended area ( beyond <header addr>+sizeof(mac_header64)+header->sizeofcmds ),
and result depends on the random content found there.

The random content interpreted as loader command might contain a large integer value in the
cmdsize field - this value is added to the current loader command pointer,
which might now point to an inaccessible memory address. It can occasionally result
in a crash if it happens to run beyond the mapped memory segment.

Note that when the area after the loader command list
contains zeros or small integers only, the loop will end normally and the problem
will go unnoticed. So it happened until now since having a some big value
after the header area, falling into command size field is a pretty rare situation.

The fix makes sure that the iterator counter gets updated when the segment load (kLCSegment)
loader command is found too, and in the same code location so the updates will always go together.

Undo the changes in the sanitizer_procmaps_mac.cpp to see the test failing.

rdar://101161047
rdar://102819707

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

Change map_nested_foreach_to_threads to ignore foreach_thread not
mapping to threads, this will allow us to call
mapNestedForeachToThreadsImpl with different set of ids to lower
multiple levels. Also adds warpIds attributes.

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

This reverts commit a772f0bb.

The main problem was related to how we handled `dbgs()` from the hosted
compiler. Using explicit `subprocess.communicate`, and not relying on
dbgs() being flushed until the end appears to address the problem.

Also some fixes due to some bots running older pythons, so we can't have
nice things like `int | float` and such.

This had no debug output. Since it was committed as NFC, it had no testcase.

The me of today was nerdsniped by the me of 6 years ago and decided that this
ought to have a testcase and some debug output.

`Mapper.UnsignedVec.begin()` never changes throughout the call to
`erase_if`, so no need to recalculate it.

Also drop some redundant braces.

If the size is < 2, then we just break anyway.

We have `using llvm`, we don't need to say `llvm::`.

The MachineOutliner + SuffixTree both used `std::vector` everywhere because I
didn't know any better at the time.

At least for small types, such as `unsigned` and iterators, I can't see any
particular reason to use std::vector over `SmallVector` here.

This reverts commit a7354899.

The way stdout/stderr get routed seems to work differently locally and
on the bots. Investigating.

This hooks up the interactive model runner to the passes that support
ml-based decisions. Because the interface to this runner is the exact
same as the one used during inference, we just reuse the exact same
setup we have for "release mode". This makes "release mode" a misnomer -
and that's something we needed to resolve sooner or later (e.g.
supporting more than one embedded model for the same problem was another
reason to drop that nomenclature). That will happen in a subsequent
change.

To use this evaluator, just enable the pass in (currently) "release"
mode, but also pass the base name for the 2 channel files via the
pass-specific flag.

The 2 files are the responsibilty of the hosting process. The added
tests use a minimal, toy such host, illustrating setup and
communication.

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

Reviewed By: aartbik

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

Reviewed By: aartbik

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

D115187 exposed CoroutineSuspendExpr's operand, which makes some nodes to show
up twice during the traversal, confusing the check for unsequenced operations.
Skip the operand since it's already handled as part of the common expression
and get rid of the misleading warnings.

https://github.com/llvm/llvm-project/issues/56768

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

Recommit with bug fixes + added testcases to the outliner. Also adds some
debug output.

We found a case in the Swift benchmarks where the MachineOutliner introduces
about a 20% compile time overhead in comparison to building without the
MachineOutliner.

The origin of this slowdown is that the benchmark has long blocks which incur
lots of LRU checks for lots of candidates.

Imagine a case like this:

```
bb:
  i1
  i2
  i3
  ...
  i123456
```

Now imagine that all of the outlining candidates appear early in the block, and
that something like, say, NZCV is defined at the end of the block.

The outliner has to check liveness for certain registers across all candidates,
because outlining from areas where those registers are used is unsafe at call
boundaries.

This is fairly wasteful because in the previously-described case, the outlining
candidates will never appear in an area where those registers are live.

To avoid this, precalculate areas where we will consider outlining from.
Anything outside of these areas is mapped to illegal and not included in the
outlining search space. This allows us to reduce the size of the outliner's
suffix tree as well, giving us a potential memory win.

By precalculating areas, we can also optimize other checks too, like whether
or not LR is live across an outlining candidate.

Doing all of this is about a 16% compile time improvement on the case.

This is likely useful for other targets (e.g. ARM + RISCV) as well, but for now,
this only implements the AArch64 path. The original "is the MBB safe" method
still works as before.

GitPython 3.1.28 has a security vulnerability which was fixed in 3.1.30:
	https://nvd.nist.gov/vuln/detail/CVE-2022-24439

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

This patch adds the final conversion to printf, %g. This is a floating
point conversion that selects automatically between the %e and %f
formats based on the precision requested and resulting exponent.
Additionally it trims trailing zeroes. With this done all that's left
for finishing printf is adding long double support to the decimal float
conversions.

Reviewed By: sivachandra

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

We were not hashing constant strings in the command-line, only ones that
required allocations. This was causing us to get the same hash across
different flag options.

rdar://101053855

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

Fix tsan problem where the per-thread shared_ptr() can be locked right before the cache is destroyed causing a race where it tries to remove an entry from a destroyed cache.

This is a rollforward with fixes of https://reviews.llvm.org/rGbcc10817d5569172ee065015747e226280e9b698 (originally https://reviews.llvm.org/D142394). The original patch exposed an asan problem on aarch64, which is fixed by simply calling the context destructors properly.

Reviewed By: rriddle

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

Reviewed By: aartbik

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

Summary:
This list previously had empty members. Fix it and print out which
architectures we're building for as a status message.

Some clients use libc++ with modules and LSV (Local Submodule Visibility)
enabled, and we see frequent downstream breakage caused by that. Until
modules use LSV by default (which is apparently a desire), add a CI job
that tests this sub-configuration to avoid high cost downstream breakage.

For more information about LSV, see https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150504/128395.html.

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