| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r322875 | dim | 2018-01-18 19:39:13 +0100 (Thu, 18 Jan 2018) | 9 lines
Add a -no-libcxxabi option to the test-release.sh script.
On FreeBSD, it is currently not possible to build libcxxabi and link
against it, so we have been building releases with -no-libs for quite
some time.
However, libcxx and libunwind should build without problems, so provide
an option to skip just libcxxabi.
------------------------------------------------------------------------
Merging r322879:
------------------------------------------------------------------------
r322879 | dim | 2018-01-18 20:30:30 +0100 (Thu, 18 Jan 2018) | 2 lines
Follow-up to rL322875 by initializing the do_libcxxabi variable properly.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@323038 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This change deals with intrinsics with multiple outputs, for example load
instrinsic with address updated.
DAG selection for Instrinsics could be done either through source code or
tablegen. Handling all intrinsics in source code would introduce a huge chunk
of repetitive code if we have a large number of intrinsic that return multiple
values (see NVPTX as an example). While intrinsic class in tablegen supports
multiple outputs, tablegen only supports Intrinsics with zero or one output on
TreePattern. This appears to be a simple bug in tablegen that is fixed by this
change.
For Intrinsics defined as:
def int_xxx_load_addr_updated: Intrinsic<[llvm_i32_ty, llvm_ptr_ty], [llvm_ptr_ty, llvm_i32_ty], []>;
Instruction will be defined as:
def L32_X: Inst<(outs reg:$d1, reg:$d2), (ins reg:$s1, reg:$s2), "ld32_x $d1, $d2, $s2", [(set i32:$d1, i32:$d2, (int_xxx_load_addr_updated i32:$s1, i32:$s2))]>;
Patch by Wenbo Sun, thanks!
Differential Revision: https://reviews.llvm.org/D32888
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Some output changes from uppercase hex to lowercase hex, no other functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Correctly handle files ignored by svn (such as .o files,
which are ignored by default) by adding "--no-ignore" flag to "svn
status" and "svn add".
Differential Revision: https://reviews.llvm.org/D41404
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Dump the failing TreePattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321282 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics about switch statements without case or default labels.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321217 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Allows preserving MachineMemOperands on intrinsics
through selection. For reasons I don't understand, this
is a static property of the pattern and the selector
deliberately goes out of its way to drop if not present.
Intrinsics already inherit from SDPatternOperator allowing
them to be used directly in instruction patterns. SDPatternOperator
has a list of SDNodeProperty, but you currently can't set them on
the intrinsic. Without SDNPMemOperand, when the node is selected
any memory operands are always dropped. Allowing setting this
on the intrinsics avoids needing to introduce another equivalent
target node just to have SDNPMemOperand set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
members
NFC for currently supported targets. This resolves a problem encountered by
targets such as RISCV that reference `Subtarget` in ImmLeaf predicates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: mehdi_amini, ioeric, klimek
Reviewed By: ioeric
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41393
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321175 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch resubmits the SVE ZIP1/ZIP2 patch series consisting of
of r320992, r320986, r320973, and r320970 by reverting
https://reviews.llvm.org/rL321024.
The issue that caused r321024 has been addressed in https://reviews.llvm.org/rL321158,
so this patch-series should be safe to resubmit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321114 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the emission
Between the creation of the last InstructionMatcher and the first
emission of the related Rule, we need to clear the internal map of IDs.
We used to do that right after the creation of the main
InstructionMatcher when building the rule and although that worked, this
is fragile because if for some reason some later code decides to create
more InstructionMatcher before the final call to emit, then the IDs
would be completely messed up.
Move that to the beginning of "emit" so that the IDs are guarantee to be
consistent.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We need to handle IR for tests that want to do lowering (or just
-stop-after with IR as input). I've run this on one AArch64 test to
demonstrate what it looks like.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For tests that do lowering we need to support IR as input, so here we
clarify some names to avoid ambiguity in upcoming commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Matchers consistent
Move InsnVarID and OpIdx at the beginning of the list of arguments
for all the constructors of the OperandMatcher subclasses.
This matches what we do for the InstructionMatcher.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In theory, reapplying optimizeRules on each group matchers should give
us a second nesting level on the matching table. In practice, we need
more work to make that happen because all the predicates are actually
not directly available through the predicate matchers list.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321025 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts changes r320992, r320986, r320973, and r320970.
r320970 by itself breaks the test case, and the rest depend on it.
Test case will land soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
*** Context ***
Prior to this patchw, the table generated for matching instruction was
straight forward but highly inefficient.
Basically, each pattern generates its own set of self contained checks
and actions.
E.g., TableGen generated:
// First pattern
CheckNumOperand 3
CheckOpcode G_ADD
...
Build ADDrr
// Second pattern
CheckNumOperand 3
CheckOpcode G_ADD
...
Build ADDri
// Third pattern
CheckNumOperand 3
CheckOpcode G_SUB
...
Build SUBrr
*** Problem ***
Because of that generation, a *lot* of check were redundant between each
pattern and were checked every single time until we reach the pattern
that matches.
E.g., Taking the previous table, let say we are matching a G_SUB, that
means we were going to check all the rules for G_ADD before looking at
the G_SUB rule. In particular we are going to do:
check 3 operands; PASS
check G_ADD; FAIL
; Next rule
check 3 operands; PASS (but we already knew that!)
check G_ADD; FAIL (well it is still not true)
; Next rule
check 3 operands; PASS (really!!)
check G_SUB; PASS (at last :P)
*** Proposed Solution ***
This patch introduces a concept of group of rules (GroupMatcher) that
share some predicates and only get checked once for the whole group.
This patch only creates groups with one nesting level. Conceptually
there is nothing preventing us for having deeper nest level. However,
the current implementation is not smart enough to share the recording
(aka capturing) of values. That limits its ability to do more sharing.
For the given example the current patch will generate:
// First group
CheckOpcode G_ADD
// First pattern
CheckNumOperand 3
...
Build ADDrr
// Second pattern
CheckNumOperand 3
...
Build ADDri
// Second group
CheckOpcode G_SUB
// Third pattern
CheckNumOperand 3
...
Build SUBrr
But if we allowed several nesting level, it could create a sub group
for the checknumoperand 3.
(We would need to call optimizeRules on the rules within a group.)
*** Result ***
With only one level of nesting, the instruction selection pass is up
to 4x faster. For instance, one instruction now takes 500 checks,
instead of 24k! With more nesting we could get in the tens I believe.
Differential Revision: https://reviews.llvm.org/D39034
rdar://problem/34670699
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321017 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Patch [4/4] in a series to add parsing of predicates and properly parse SVE ZIP1/ZIP2 instructions. This patch further improves diagnostic messages for when the SVE feature is not specified.
Reviewers: rengolin, fhahn, olista01, echristo, efriedma
Reviewed By: fhahn
Subscribers: sdardis, aemerson, javed.absar, tschuett, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D40363
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instruction
Summary:
When emitting a diagnostic for an invalid operand, a specific diagnostic
should only be reported when the instruction being matched is actually
enabled by the feature flags.
Patch [3/4] in a series to add parsing of predicates and properly parse SVE
ZIP1/ZIP2 instructions. This patch fixes bogus diagnostic messages for when
the SVE feature is not specified.
Reviewers: rengolin, craig.topper, olista01, sdardis, stoklund
Reviewed By: olista01, sdardis
Subscribers: fhahn, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D40362
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This opens refactoring opportunities in the match table now that we can
check that two predicates are the same.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320890 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Introduced in r320887.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dealing with
Prior to this patch, a predicate wouldn't make sense outside of its
rule. Indeed, it was only during emitting a rule that a predicate would
be made aware of the IDs of the data it is checking. Because of that,
predicates could not be moved around or compared between each other.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Now that r320495, "[debuginfo-tests] Support moving
debuginfo-tests to llvm/projects," has landed, which includes a local
copy of test_debuginfo.pl, remove the obsolete copy.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D41260
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Hexagon HVX has type v128i8, comparing two vectors of that type will
produce v128i1 types in SelectionDAG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The generated diagnostic by the AsmMatcher isn't always applicable to the AsmOperand.
This is because the code will only update the diagnostic if it is more
specific than the previous diagnostic. However, when having validated
operands and 'moved on' to a next operand (for some instruction/alias for
which all previous operands are valid), if the diagnostic is InvalidOperand,
than that should be set as the diagnostic, not the more specific message
about a previous operand for some other instruction/alias candidate.
(Re-committed with an extra whitespace in SVEInstrFormats.td to trigger rebuild
of AArch64GenAsmMatcher.inc, since the llvm-clang-x86_64-expensive-checks-win
builder does not seem to rebuild AArch64GenAsmMatcher.inc with the
newly built TableGen due to a missing dependency somewhere (see:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119555.html))
Reviewers: craig.topper, olista01, rengolin, stoklund
Reviewed By: olista01
Subscribers: javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D40011
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
*GenInstrInfo.inc with GET_INSTRINFO_ENUM. Make targets request is separately.
Most of the targets don't need the scheduler class enum.
I have an X86 scheduler model change that causes some names in the enum to become about 18000 characters long. This is because using instregex in scheduler models causes the scheduler class to get named with every instruction that matches the regex concatenated together. MSVC has a limit of 4096 characters for an identifier name. Rather than trying to come up with way to reduce the name length, I'm just going to sidestep the problem by not including the enum in X86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in UB).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A number of architectures re-use the same register names (e.g. for both 32-bit
FPRs and 64-bit FPRs). They are currently unable to use the tablegen'erated
MatchRegisterName and MatchRegisterAltName, as tablegen (when built with
asserts enabled) will fail.
When the AllowDuplicateRegisterNames in AsmParser is set, duplicated register
names will be tolerated. A backend can then coerce registers to the desired
register class by (for instance) implementing validateTargetOperandClass.
At least the in-tree Sparc backend could benefit from this, as does RISC-V
(single and double precision floating point registers).
Differential Revision: https://reviews.llvm.org/D39845
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320018 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
opcode and enable for AArch64.
Some concerns were raised with the direction. Revert while we discuss it and look into an alternative
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The released Apple LLVM versions don't support LSan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319738 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
enable for AArch64.
This patch splits atomics out of the generic G_LOAD/G_STORE and into their own
G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a
necessary one. Atomic load/store has little in implementation in common with
non-atomic load/store. They tend to be handled very differently throughout the
backend. It also has the nice side-effect of slightly improving the common-case
performance at ISel since there's no longer a need for an atomicity check in the
matcher table.
All targets have been updated to remove the atomic load/store check from the
G_LOAD/G_STORE path. AArch64 has also been updated to mark
G_ATOMIC_LOAD/G_ATOMIC_STORE legal.
There is one issue with this patch though which also affects the extending loads
and truncating stores. The rules only match when an appropriate G_ANYEXT is
present in the MIR. For example,
(G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X))))
will match but:
(G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X))
will not. This shouldn't be a problem at the moment, but as we get better at
eliminating extends/truncates we'll likely start failing to match in some
cases. The current plan is to fix this in a patch that changes the
representation of extending-load/truncating-store to allow the MMO to describe
a different type to the operation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The variable named `minor` was actually pointing to the patch part of
the version. While I was changing this I also made the check for Apple
clang more robust by checking both patch and minor rather than just
minor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is causing a failure in the llvm-clang-x86_64-expensive-checks-win
buildbot, and I can't reproduce it locally, so reverting until I can work out
what is wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds a "invalid operands for instruction" diagnostic for
instructions where there is an instruction encoding with the correct
mnemonic and which is available for this target, but where multiple
operands do not match those which were provided. This makes it clear
that there is some combination of operands that is valid for the current
target, which the default diagnostic of "invalid instruction" does not.
Since this is a very general error, we only emit it if we don't have a
more specific error.
Differential revision: https://reviews.llvm.org/D36747
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319649 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes build when using this attribute combination
on an intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Added some commonly used Arm triples to the script, with and without
the -eabi suffix.
Differential Revision: https://reviews.llvm.org/D40708
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The latest clang that ships with Xcode (clang 900 or 9.0.0) does not
support LSan. This fixes the lit configuration to reflect that.
Differential revision: https://reviews.llvm.org/D40672
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
internally
Summary:
The internal shell already supports 'cd', ‘export’ and ‘echo’ commands.
This patch adds implementation of non-pipelined ‘mkdir’, ‘diff’ and ‘rm’
commands as the internal shell builtins.
Reviewed by: Zachary Turner, Reid Kleckner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39567
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No test yet because the relevant rules are blocked on the atomic_load,
and atomic_store nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This enables a few rules such as ARM's uxtb instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D40589
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D40520
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
G_ATOMICRMW_* rules from SelectionDAG.
GIM_CheckNonAtomic has been replaced by GIM_CheckAtomicOrdering to allow it to support a wider
range of orderings. This has then been used to import patterns using nodes such
as atomic_cmp_swap, atomic_swap, and atomic_load_*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319232 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add support for mips, particularly skipping the matching of .frame, .(f)mask
and LLVM's usage of the .set no(reorder|at|macro) directives.
Reviewers: spatel
Differential Revision: https://reviews.llvm.org/D40268
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318914 91177308-0d34-0410-b5e6-96231b3b80d8
|
