all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

llvm-svn: 351731

Reports correct size and tags when either size is not power of two
or offset to bad granule is not zero.

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

llvm-svn: 351730

llvm-svn: 351729

llvm-svn: 351728

llvm-svn: 351727

llvm-svn: 351726

This patch introduces the field `ExpressionSize` in SCEV. This field is
calculated only once on SCEV creation, and it represents the complexity of
this SCEV from arithmetical point of view (not from the point of the number
of actual different SCEV nodes that are used in the expression). Roughly
saying, it is the number of operands and operations symbols when we print this
SCEV.

A formal definition is following: if SCEV `X` has operands
  `Op1`, `Op2`, ..., `OpN`,
then
  Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN).
Size of SCEVConstant and SCEVUnknown is one.

Expression size may be used as a universal way to limit SCEV transformations
for huge SCEVs. Currently, we have a bunch of options that represents various
limits (such as recursion depth limit) that may not make any sense from the
point of view of a LLVM users who is not familiar with SCEV internals, and all
these different options pursue one goal. A more general rule that may
potentially allow us to get rid of this redundancy in options is "do not make
transformations with SCEVs of huge size". It can apply to all SCEV traversals
and transformations that may need to visit a SCEV node more than once, hence
they are prone to combinatorial explosions.

This patch only introduces SCEV sizes calculation as NFC, its utilization will
be introduced in follow-up patches.

Differential Revision: https://reviews.llvm.org/D35989
Reviewed By: reames

llvm-svn: 351725

Summary:
Add R_RISCV_RELAX relocation to all possible relax candidates and
update corresponding testcase.

Reviewers: asb, apazos

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

llvm-svn: 351723

Patch rL322965 changed how intrinsics for memset and memzero
were defined. This causes a regression in LLGO making it no
longer buidable. In addition to that one pass was renamed,
so this also addresses the pass naming disparity.

I removed all split stack related bits from this patch as
as asked.

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

llvm-svn: 351722

This updates the AVR Select8/Select16 expansion code so that, when
inserting the two basic blocks for true and false conditions, any
existing fallthrough on the previous block is preserved.

Prior to this patch, if the block before the Select pseudo fell through
to the subsequent block, two new basic blocks would be inserted at the
prior fallthrough point, changing the fallthrough destination.

The predecessor or successor lists were not updated, causing the
BranchFolding pass at -O1 and above the rearrange basic blocks, causing
an infinite loop. Not to mention the unconditional fallthrough to the
true block is incorrect in of itself.

This patch modifies the Select8/16 expansion so that, if inserting true
and false basic blocks at a fallthrough point, the implicit branch is
preserved by means of an explicit, unconditional branch to the previous
fallthrough destination.

Thanks to Carl Peto for reporting this bug.

This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123.

llvm-svn: 351721

Prior to this, the code was missing AVR-specific relocation logic in
RelocVisitor.h.

This patch teaches RelocVisitor about R_AVR_16 and R_AVR_32.

Debug information is emitted in the final object file, and understood by
'avr-readelf --debug-dump' from AVR-GCC.

llvm-dwarfdump is yet to understand how to dump AVR DWARF symbols.

llvm-svn: 351720

This reverts commit r351718.

Carl pointed out that the unit test could be improved.

This patch will be recommitted once the test is made more resilient.

llvm-svn: 351719

This updates the AVR Select8/Select16 expansion code so that, when
inserting the two basic blocks for true and false conditions, any
existing fallthrough on the previous block is preserved.

Prior to this patch, if the block before the Select pseudo fell through
to the subsequent block, two new basic blocks would be inserted at the
prior fallthrough point, changing the fallthrough destination.

The predecessor or successor lists were not updated, causing the
BranchFolding pass at -O1 and above the rearrange basic blocks, causing
an infinite loop. Not to mention the unconditional fallthrough to the
true block is incorrect in of itself.

This patch modifies the Select8/16 expansion so that, if inserting true
and false basic blocks at a fallthrough point, the implicit branch is
preserved by means of an explicit, unconditional branch to the previous
fallthrough destination.

Thanks to Carl Peto for reporting this bug.

This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123.

llvm-svn: 351718

llvm-svn: 351717

llvm-svn: 351716

llvm-svn: 351715

Summary:
Make Sanitizer Coverage work when compiled work when compiler-rt
is compiled with MSVC.

The previous solution did not work for MSVC because MSVC tried to
align the .SCOV$CZ section even though we used
__declspec(align(1)) on its only symbol:
__stop___sancov_cntrs.
Because the counter array is composed
of 1 byte elements, it does not always end on an 8 or 4 byte
boundary. This means that padding was sometimes added to
added to align the next section, .SCOV$CZ.
Use a different strategy now: instead of only instructing
the compiler not to align the symbol, make the section
one byte long by making its only symbol a uint8_t, so that
the linker won't try to align it.

Reviewers: morehouse, rnk

Reviewed By: rnk

Subscribers: kubamracek

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

llvm-svn: 351714

This implements `mi_extra_init(...)` for the ASan allocator on
Darwin and uses the `__lsan::GetAllocatorGlobalRange(...)` function
to retrieve the allocator pointer and size.

rdar://problem/45284065

llvm-svn: 351713

`sanitizer_malloc_introspection_t` and initialize them to zero.

We allow sanitizer implementations to perform different initialization
by defining `COMMON_MALLOC_HAS_EXTRA_INTROSPECTION_INIT` to be `1`
and providing an implementation of `mi_extra_init(...)`.

We use these changes in future patches to implement malloc zone enumeration.

rdar://problem/45284065

llvm-svn: 351712

enumerator.

This is done by defining `COMMON_MALLOC_HAS_ZONE_ENUMERATOR` to `1` and
then by providing an implementation of the `mi_enumerator(...)` function.
If a custom implementation isn't desired the macro is set to `0` which
causes a stub version (that fails) to be used.

Currently all Darwin sanitizers that have malloc implementations define
this to be `0` so there is no functionality change.

rdar://problem/45284065

llvm-svn: 351711

Using static library is already a default.

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

llvm-svn: 351710

-DNDEBUG is no longer needed now that we don't enable assertions,
modules should improve build times for the second stage.

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

llvm-svn: 351709

[X86] Add missing test cases for some int/fp->fp conversion intrinsics with rounding mode. Use non-default rounding mode on some tests.

For some reason we were missing tests for several unmasked conversion intrinsics, but had their mask form.

Also use a non-default rounding mode on some tests to provide better coverage for a future patch.

llvm-svn: 351708

llvm-svn: 351707

llvm-svn: 351706

llvm-svn: 351705

r339720 already disabled it in the driver

llvm-svn: 351704

llvm-svn: 351703

llvm-svn: 351702

As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.

This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.

Note that the following specialization were invalid:

    std::pair<T0, T1>
    llvm::Optional<T>

Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.

As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)

Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.

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

llvm-svn: 351701

llvm-svn: 351700

llvm-svn: 351699

There is a combine that was hiding these tests
not actually testing what they should be, although
they were producing the expected end result.

llvm-svn: 351698

This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp.

Noticed while cleaning up vector integer comparison costs for PR40376.

llvm-svn: 351697

llvm-svn: 351696

llvm-svn: 351695

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: kristina, cfe-commits

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

llvm-svn: 351694

This was crashing in the predicate function assuming the value
is a vector.

Copy more of what AArch64 uses. This probably needs more refinement
later, but I don't exactly understand what it means in some cases,
particularly since any legalization for these seems to be missing.

llvm-svn: 351693

llvm-svn: 351692

llvm-svn: 351691