In 0e9b0b6d I introduced the
HistoryOperation enum to navigate the history. While this fixed the
behavior of HistoryOperation::Older and HistoryOperation::Newer, it
confused the mapping for HistoryOperation::Oldest and
HistoryOperation::Newest.

I tried to write a PExpect test to make sure this doesn't regress, but
I'm unable to prime the history in such a way that it recalls a known
element. I suspect this is an LLDB bug, but the  most recent entry
doesn't get update with entries from the current session. I considered
spoofing the home directory but that needs to happen before libLLDB is
loaded and you'll need to account for the widechar support. If anyone
has another suggestion I'd love to hear it.

[NFC][llvm-exegesis] CombinationGenerator::performGeneration(): pull put state increment into lambda

This avoids questionable code such as taking address of current
range-based for variable and comparing it with vector begin iterator.
While this may not be a problem in itself, it can be written more consice.
This was initially suggested by @aaronpuchert.

This change makes the following lit substitutions expand to the correct
thing for macOS, iOS, tvOS, and watchOS.

%darwin_min_target_with_full_runtime_arc_support
%macos_min_target_10_11

rdar://problem/59463146

rdar://problem/59466685

[compiler-rt] Provide a lit config variable that defines the minimum deployment OS version flag appropriate for the configured OS.

This patch defines `config.apple_platform_min_deployment_target_flag`
in the ASan, LibFuzzer, TSan, and UBSan lit test configs.

rdar://problem/59463146

rdar://problem/59463146

platforms.

For the simulators this changes the following compilation flags (
used both for building the runtime and lit tests).

iOS simulator: `-miphoneos-version-min` -> `-mios-simulator-version-min`
watchOS simulator: `-mwatchos-version-min` -> `-mwatchos-simulator-version-min`
tvOS simulator: `-mtvos-version-min` -> `-mtvos-simulator-version-min`

rdar://problem/59463146

[llvm-exegesis] Rename range based for loop variable in a unit test so its different than the container being iterated over. NFC

It seems like gcc 5.5 wants to iterate over the new variable instead
of the container that lives outside the loop. But of course this
new container is empty.

Plus using a different variable names makes the code more readable.

The array seemed to have decayed to a pointer before the ArrayRef
constructor got called so there was no size information available.

This patch extends affine data copy optimization utility with an
optional memref filter argument. When the memref filter is used, data
copy optimization will only generate copies for such a memref.

Note: this patch is just porting the memref filter feature from Uday's
'hop' branch: https://github.com/bondhugula/llvm-project/tree/hop.

Reviewed By: bondhugula

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

Summary:
Add a method to set the release to OS value as the system runs,
and allow this to be set differently in the primary and the secondary.
Also, add a default value to use for primary and secondary. This
allows Android to have a default that is different for
primary/secondary.

Update mallopt to support setting the release to OS value.

Reviewers: pcc, cryptoad

Reviewed By: cryptoad

Subscribers: cryptoad, jfb, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

In https://reviews.llvm.org/rG8b737688c21a9755cae14cb9343930e0882164ab I
switched the condition gating the creation of the descriptor symbol from
checking the MCAsmInfo if we need to support descriptors, to if the OS
was AIX. Technically the 2 should be interchangeable: if we are
targeting AIX then we need to emit XCOFF object files, and the MCAsmInfo
must return true for needing function descriptors.

This doesn't account for lit test with runsteps that only set the arch.
Eg: test/CodeGen/XCore/section-name.ll
which when run natively on AIX we end up with a target xcore-ibm-aix and
needFunctionDescriptors is false.

This patch reverts to using the MCAsmInfo and adds an assert that the
target OS must be AIX since that is the only target using the descriptor
hook.

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

This is like -fdata-sections, and it's not part of /O2 by default for some reason.

In the cmake build, reduces the size of clang.exe from 70,358,016 bytes to 69,982,720 bytes.

clang-format.exe goes from 3,703,296 bytes to 3,331,072 bytes.

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

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

Repeat the build instructions from the top level README in the Getting
Started guide.

The division expansions in AMDGPUCodeGenPrepare can't be relied on for
correctness, since they punt to later optimization and possibly
legalization in some cases. We still need a way to be able to write
tests for the legalizer versions of the expansion. This is mostly for
GlobalISel, since the expected optimzations is expecting aren't
implemented.

The interaction with the flag to expand 64-bit division in the IR is
pretty confusing, but these flags have different purposes.

I updated the prefix and forgot to manually remove the old names
as part of rG6071fc57.f

The existing checks were trying to test both CPU-specific
codegen and generic codegen with explicit attributes for
the various sqrt estimate possibilities, but that was hard
to decipher and update (D69989).

Instead generate the complete results for various CPUs,
and that makes it clear which models have slow/fast sqrt
attributes along with all of the other potential diffs
(FMA, AVX2, scheduling).

Also, explicitly add the function attributes corresponding
to whether DAZ/FTZ denorm settings are expected.

I didn't realize we were already expanding 24/32-bit division here
already. Use the available IntegerDivision utilities. This uses loops,
so produces significantly smaller code than the inline DAG expansion.

This now requires width reductions of 64-bit divisions before
introducing the expanded loops.

This helps work around missing legalization in GlobalISel for
division, which are the only remaining core instructions that didn't
work at all.

I think this is plausibly a better implementation than exists in the
DAG, although turning it on by default misses out on the constant
value optimizations and also needs benchmarking.

Summary:
Potential fix for: https://bugs.llvm.org/show_bug.cgi?id=44889 and https://bugs.llvm.org/show_bug.cgi?id=44408

In the legacy pass manager, loop rotate need not compute MemorySSA when not being in the same loop pass manager with other loop passes.
There isn't currently a way to differentiate between the two cases, so this attempts to limit the usage in LoopRotate to only update MemorySSA when the analysis is already available.
The side-effect of this is that it will split the Loop pipeline.

This issue does not apply to the new pass manager, where we have a flag specifying if all loop passes in that loop pass manager preserve MemorySSA.

Reviewers: dmgreen, fedor.sergeev, nikic

Subscribers: Prazek, hiraditya, george.burgess.iv, llvm-commits

Tags: #llvm

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

This is more or less directly ported from the AMDGPU custom lowering
for FP_TO_FP16. I made a few minor fixups (using G_UNMERGE_VALUES
instead of creating shift/trunc to extract the two halves, and zexting
an inverted compare instead of select_cc).

This also does not include the fast math expansion the DAG which
converts to f32 and then to f16. I think that belongs in a
pre-legalize combine instead.

Like COPY instructions explained in D70616, we don't check the constraints
when combining G_UNMERGE_VALUES. Use the same logic used in D70616 to check
if registers can be replaced, or a COPY instruction needs to be built.

https://reviews.llvm.org/D70564

Assembler now permits pairs like 'v0:1', which are encoded
differently from the odd-first pairs like 'v1:0'.

The compiler will require more work to leverage these new register
pairs.

We don't want to test for this warning, so we just fix it.

Summary:
Zero-parameter K&R definitions specify that the function has no
parameters, but they are still not prototypes, so calling the function
with the wrong number of parameters is just a warning, not an error.

The C11 standard doesn't seem to directly define what a prototype is,
but it can be inferred from 6.9.1p7: "If the declarator includes a
parameter type list, the list also specifies the types of all the
parameters; such a declarator also serves as a function prototype
for later calls to the same function in the same translation unit."
This refers to 6.7.6.3p5: "If, in the declaration “T D1”, D1 has
the form
    D(parameter-type-list)
or
    D(identifier-list_opt)
[...]". Later in 6.11.7 it also refers only to the parameter-type-list
variant as prototype: "The use of function definitions with separate
parameter identifier and declaration lists (not prototype-format
parameter type and identifier declarators) is an obsolescent feature."

We already correctly treat an empty parameter list as non-prototype
declaration, so we can just take that information.

GCC also warns about this with -Wstrict-prototypes.

This shouldn't affect C++, because there all FunctionType's are
FunctionProtoTypes. I added a simple test for that.

Reviewed By: aaron.ballman

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

As noted on D74621 we currently have no test coverage

Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to
avoid name conflict.

This was caused by byte depending on traits. This patch moves
the minimal amount of meta-programming into <cstddef> to break the cycle.

Also fix BitVector unittest failure when DLLVM_ENABLE_ASSERTIONS are OFF, introduced by d110c3a9.

AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`.
It works with lld and GNU ld, and adds other LTO options.
So AddGoldPlugin is no longer a suitable name.

Reviewed By: tejohnson

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

Reverting D73027 [DependenceAnalysis] Dependecies for loads marked with "ivnariant.load" should not be shared with general accesses(PR42151).