NFC

llvm-svn: 330631

Reland r329956, "AArch64: Introduce a DAG combine for folding offsets into addresses.", with a fix for the bot failure.

This reland includes a check to prevent the DAG combiner from folding an
offset that is smaller than the existing one. This can cause oscillations
between two possible DAGs, which was the cause of the hang and later assertion
failure observed on the lnt-ctmark-aarch64-O3-flto bot.
http://green.lab.llvm.org/green/job/lnt-ctmark-aarch64-O3-flto/2024/

Original commit message:
> This is a code size win in code that takes offseted addresses
> frequently, such as C++ constructors that typically need to compute
> an offseted address of a vtable. This reduces the size of Chromium
> for Android's .text section by 108KB.

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

llvm-svn: 330630

Summary:
This change teaches DSE that the atomic memory intrinsics are stores
that can be eliminated, and can allow other stores to be eliminated.
This change specifically does not teach DSE that these intrinsics
can be partially eliminated (i.e. length reduced, and dest/src changed);
that will be handled in another change.

Reviewers: mkazantsev, skatkov, apilipenko, efriedma, rsmith

Reviewed By: efriedma

Subscribers: dmgreen, llvm-commits

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

llvm-svn: 330629

This patch adds a cost model test case for vector shuffles having transpose
masks. The given costs are inaccurate and will be updated in a follow-on patch.

llvm-svn: 330625

For now switch back to fixed shadow mapping for x86-64 due to the issues
with IFUNC linking on older binutils. More details will be added to
https://bugs.chromium.org/p/chromium/issues/detail?id=835864

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

llvm-svn: 330623

This demonstrates a bug where the encoding for a 16-bit bswap prints a 16-bit register and a 32-bit mnemonic. Intel docs say 16-bit bswap is undefined. We should either claim it as an invalid encoding or we should print a 16-bit mnemonic.

objdump does print the encoding as bswap with a 16-bit register. But it doesn't seem to ever print a suffix.

llvm-svn: 330621

This helps debug issues where selection-dag assigns the wrong location
to an instruction.

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

llvm-svn: 330618

Only add support for getSchedInfoStr(const MachineInstr &MI) at the TargetSubtargetInfo level.

Really, the getSchedInfoStr calls need to be removed entirely, we should just return a latency/rthroughput through the subtarget and keep a string creation helper function somewhere else.

llvm-svn: 330615

llvm-svn: 330614

It's possible to validly spill the frame offset register
in a call sequence to a VGPR. There are definitely issues
with SGPR spilling to memory, so move the assert later.

llvm-svn: 330612

llvm-svn: 330611

We use llvm-symbolizer in some production systems, and we run it
against all possibly related files, including some that are not
ELF. We noticed that for some of those invalid files, llvm-symbolizer
would crash with SEGFAULT. Here is an example of such a file.

It is due to that in computeSymbolSizes, a loop uses condition

  for (unsigned I = 0, N = Addresses.size() - 1; I < N; ++I) {

where if Addresses.size() is 0, N would overflow and causing the loop
to access invalid memory.

Instead of patching the loop conditions, the commit makes so that the
function returns early if Addresses is empty.

Validated by checking that llvm-symbolizer no longer crashes.

Patch by Teng Qin!

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

llvm-svn: 330610

Also assert that it is correct for SGPRs. There is currently a bug
where stack slot coloring replaces SGPR spill FIs with one with
the default ID, which results in a more confusing assert later
about a dead object.

llvm-svn: 330607

llvm-svn: 330606

Summary:
This just refactors the lowering of the atomic memory intrinsics to more
closely match the code patterns used in the lowering of the non-atomic
memory intrinsics. Specifically, we encapsulate the lowering in
SelectionDAG::getAtomicMem*() functions rather than embedding
the code directly in the SelectionDAGBuilder code.

llvm-svn: 330603

Summary: Move Go bindings for subranges and DINode arrays.

Reviewers: harlanhaskins, whitequark, deadalnix

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 330594

llvm-svn: 330593

variables, NFC.

llvm-svn: 330592

Summary: Adds bindings for Module and NameSpace scopes and LLVMDIBuilderCreateForwardDecl, a counterpart to LLVMDIBuilderCreateReplaceableCompositeType.

Reviewers: harlanhaskins, whitequark, deadalnix

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 330591

Summary:
This patch removes references to AliasAnalysisCounter pass from the AliasAnalysis documentation. That pass have been eliminated in 2015, at revision trunk@247167.

Reviewed By: hfinkel

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

llvm-svn: 330590

Note - noticed this as the STAC case as it was unintentionally matching against *STACK* pseudo instructions.

llvm-svn: 330588

llvm-svn: 330587

Summary:
Found by inspection. We care about the operand that *doesn't*
contain the immediate.

I believe this is currently not hit because we fold 0xff / 0xffff
immediates only later.

Change-Id: Ic3cf8538bc7da5eff3200d96eccf9d339e6345a7

Reviewers: arsenm, rampitec

Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 330586

Summary:
See the new test case; this is really unlikely to happen with real code,
but I ran into this while attempting to bugpoint-reduce a different issue.

Change-Id: I9ade1dc1aa8fd9c4d9fc83661d7b80e310b5c4a6

Reviewers: arsenm, rampitec

Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 330585

llvm-svn: 330584

Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro

Reviewed By: rengolin

Subscribers: tschuett, kristof.beyls, llvm-commits

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

llvm-svn: 330583

LoopRotate only invalidates innermost loops while the changes that it makes may
also affert any of this parents. With patch rL329047, SCEV becomes much smarter
about calculation of exit counts for outer loops, so we cannot assume that they are
not affected.

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

llvm-svn: 330582

llvm-svn: 330581

Current runtime unrolling invalidates parent loop saying that it might have changed
after the inner loop has changed, but it doesn't bother to do the same to its parents.
With patch rL329047, SCEV becomes much smarter about calculation of exit counts for
outer loops. We might need to invalidate not only the immediate parent, but also
any of its parents as well.

There is no clear evidence that there is some miscompile happening because of this
(at least I don't have such test), but the common sense says that the current code
is wrong.

Differential Revision: https://reviews.llvm.org/D45940
Reviewed By: chandlerc

llvm-svn: 330577

In the function `simplifyOneLoop` we optimistically assume that changes in the
inner loop only affect this very loop and have no impact on its parents. In fact,
after rL329047 has been merged, we can now calculate exit counts for outer
loops which may depend on inner loops. Thus, we need to invalidate all parents
when we do something to a loop.

There is an evidence of incorrect behavior of `simplifyOneLoop`: when we insert
`SE->verify()` check in the end of this funciton, it fails on a bunch of existing
test, in particular:

    LLVM :: Transforms/LoopUnroll/peel-loop-not-forced.ll
    LLVM :: Transforms/LoopUnroll/peel-loop-pgo.ll
    LLVM :: Transforms/LoopUnroll/peel-loop.ll
    LLVM :: Transforms/LoopUnroll/peel-loop2.ll

Note that previously we have fixed issues of this variety, see rL328483.
This patch makes this function invalidate the outermost loop properly.

Differential Revision: https://reviews.llvm.org/D45937
Reviewed By: chandlerc

llvm-svn: 330576

Summary:
In the course of writing an experimental ANTLR grammar based on this
document, I found three errors in the documented BNF:

SimpleValues of dag type are allowed to have no operands at all after
the initial DagArg specifying the operator. For example, the value
(outs) is extremely common in backends; an example in the test suite
is test/TableGen/AsmVariant.td line 30. But the BNF doesn't allow
DagArgList to expand to the empty string (it must contain at least one
DagArg), and therefore the DagArgList specifying the operands in the
dag-shaped production for SimpleValue should be optional.

In the production for BodyItem with a 'let' and an optional RangeList,
the RangeList should have braces around it if it's present, matching
code such as "let E{7-0} = ..." on test/TableGen/BitsInit.td line 42.
Those braces aren't included in the RangeList nonterminal itself, so
instead they need to be part of the optional segment of the BodyItem
production.

Finally, the identifier after 'defm' should be optional. Again, this
is very common in the real back end .td files; an example in the test
suite is in test/TableGen/defmclass.td line 49.

Reviewers: rengolin, nhaehnle, stoklund

Reviewed By: nhaehnle

Subscribers: llvm-commits

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

llvm-svn: 330570

Should be a harmless trimming of trailing whitespace from a
documentation file.

(There are other instances of trailing whitespace in this file alone.
I've only fixed one of them, on the basis that that way the rest are
still available for other people's commit-access tests :-)

llvm-svn: 330567

Reviewers: fhahn, rengolin, javed.absar, SjoerdMeijer, t.p.northover, echristo, evandro, huntergr

Reviewed By: rengolin

Subscribers: tschuett, kristof.beyls, llvm-commits

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

llvm-svn: 330565

The condition this was asserting doesn't actually hold. I've added
comments to explain why, removed the assert, and added a fun test case
reduced out of 403.gcc.

llvm-svn: 330564

llvm-svn: 330563

llvm-svn: 330560

llvm-svn: 330558

The SandyBridge BMI tests are actually run on IvyBridge as that's the first lowest CPU that actually support the ISAs (but still use the SandyBridge model).

llvm-svn: 330556

Summary: Wrap LLVMDIBuilderCreateAutoVariable, LLVMDIBuilderCreateParameterVariable, LLVMDIBuilderCreateExpression, and move and correct LLVMDIBuilderInsertDeclareBefore and LLVMDIBuilderInsertDeclareAtEnd from the Go bindings to the C bindings.

Reviewers: harlanhaskins, whitequark, deadalnix

Reviewed By: harlanhaskins, whitequark

Subscribers: llvm-commits

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

llvm-svn: 330555

Fixed a lot of the default classes which were being completely overridden.

llvm-svn: 330554