Commit Graph

7411 Commits

Author SHA1 Message Date
David L. Jones d387fd0f75 gn build: merge r360345
llvm-svn: 360489
2019-05-11 00:20:18 +00:00
Stella Stamenova 46b9d19cc0 Use UNSUPPORTED: windows in shtest-timeout.py. Apparently system-windows does not cover all cases either and the case it doesn't cover affects one of the buildbots.
llvm-svn: 360373
2019-05-09 20:22:02 +00:00
Stella Stamenova bc9e086693 Use UNSUPPORTED: system-windows instead of REQUIRES: nowindows or UNSUPPORTED: windows. nowindows is not currently defined and windows does not cover all cases. system-windows is also consistent with how other platforms are used.
llvm-svn: 360368
2019-05-09 19:40:21 +00:00
Paul Robinson 0b68fc3f59 Re-enable lit test shtest-timeout.py on non-Windows.
It was disabled incorrectly, which meant it wasn't running anywhere.

llvm-svn: 360356
2019-05-09 17:01:03 +00:00
Nico Weber 82e68f5d6a gn build: Merge r960255
llvm-svn: 360343
2019-05-09 14:14:21 +00:00
Alex Lorenz a438a898b0 lit config: disable LSan for Apple clang compiler in addition to Apple LLVM
Apple clang is the canonical way to refer to the compiler shipped with Xcode.

llvm-svn: 360307
2019-05-09 02:46:20 +00:00
Nico Weber cc433095f2 gn build: Merge r360151
llvm-svn: 360253
2019-05-08 13:41:01 +00:00
Jonas Devlieghere fe608c938c Revert "[OpenMP][Clang] Support for target math functions"
This commit appears to be breaking stage-2 builds on GreenDragon. The
OpenMP wrappers for cmath and math.h are copied into the root of the
resource directory and cause a cyclic dependency in module 'Darwin':
Darwin -> std -> Darwin. This blows up when CMake is testing for modules
support and breaks all stage 2 module builds, including the ThinLTO bot
and all LLDB bots.

CMake Error at cmake/modules/HandleLLVMOptions.cmake:497 (message):
  LLVM_ENABLE_MODULES is not supported by this compiler

llvm-svn: 360192
2019-05-07 21:08:15 +00:00
Nico Weber 719a9aed05 gn build: Merge r360116
llvm-svn: 360141
2019-05-07 13:07:23 +00:00
Nico Weber f8759e499c gn build: Run `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`
llvm-svn: 360140
2019-05-07 13:02:18 +00:00
Krasimir Georgiev 866e05f023 Revert "[TableGen] Fix a typo"
Summary:
This reverts commit r360106.

The revisioin causes llvm-tblgen to hang while generating info for
RISCV.td. The root cause might be in the RISCV.td definition but I don't
know enough about this to investigate further.

Command that starts hangning after r360106:
`llvm-build/bin/llvm-tblgen -I llvm/include -I llvm/tools/clang/include -I llvm/lib/Target/RISCV -gen-instr-info llvm/lib/Target/RISCV/RISCV.td`

Reviewers: sammccall, yan_luo, craig.topper, gribozavr

Reviewed By: gribozavr

Subscribers: PkmX, llvm-commits

Tags: #llvm

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

llvm-svn: 360136
2019-05-07 11:39:35 +00:00
Yan Luo 55ed2f5309 [TableGen] Fix a typo
Check "Big" instead of "Small" in the second condition.

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

llvm-svn: 360106
2019-05-07 01:07:46 +00:00
Peter Collingbourne 2d2277f5e7 gn build: Merge r360063.
llvm-svn: 360074
2019-05-06 20:09:12 +00:00
Nico Weber a2e23f682a gn build: More TODO tweaking
Differential Revision: https://reviews.llvm.org/D61468

llvm-svn: 360057
2019-05-06 17:17:41 +00:00
Nico Weber b2fe1a8f59 gn build: Update TODO now that libcxx libcxxabi libunwind clang-tools-extra are done
Differential Revision: https://reviews.llvm.org/D61468

llvm-svn: 360056
2019-05-06 17:15:19 +00:00
Nico Weber f0540a9e4e gn build: Merge r360018
llvm-svn: 360049
2019-05-06 15:06:43 +00:00
Petr Hosek 6971a166d9 [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not defining them
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

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

llvm-svn: 360004
2019-05-06 01:25:31 +00:00
Petr Hosek 741f52ca62 [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

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

llvm-svn: 360003
2019-05-06 01:22:28 +00:00
Craig Topper 99f8c4f5b6 Make the git-llvm script work on older git versions that don't support git rev-parse --git-common-dir.
Not all versions of git support git rev-parse --git-common-dir. Rather than erorr or print any kind of
useful error, they just print back '--git-common-dir' instead of a directory. The git-llvm script
ends up taking this '--git-common-dir' as a diretory name to use.

Not sure exactly what happens after that, but the end result is that the 'git llvm push' ends up
looking like it pushed your commits, but really did nothing.

This patch makes the script detect the bogus directory name for --git-common-dir and falls back to using --git-dir instead.

llvm-svn: 359939
2019-05-03 22:03:29 +00:00
Nico Weber e041673432 gn build: Merge r359878
llvm-svn: 359888
2019-05-03 14:27:12 +00:00
Petr Hosek 6e9cfee63a [gn] Include the missing BUILD.gn file for libcxxabi includes
This was omitted in r359805.

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

llvm-svn: 359828
2019-05-02 21:20:08 +00:00
Petr Hosek 206bc17ea0 [gn] Update the clangd test lit site configuration
This reflects changes made in r359763.

llvm-svn: 359825
2019-05-02 20:34:54 +00:00
Petr Hosek 40028046cd [gn] Include libcxx configuration file
This was omitted in r359806 but is already referenced in the GN build.

llvm-svn: 359815
2019-05-02 19:07:23 +00:00
Petr Hosek fa3c328c51 [gn] Support for building libc++
This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.

We only support two stage build at the moment.

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

llvm-svn: 359806
2019-05-02 17:29:41 +00:00
Petr Hosek 4fe63c70c7 [gn] Support for building libcxxabi
This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.

We only support two stage build at the moment.

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

llvm-svn: 359805
2019-05-02 17:29:39 +00:00
Petr Hosek f0652f03b6 [gn] Support for building libunwind
This change introduces support for building libuwind. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.

We only support two stage build at the moment.

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

llvm-svn: 359804
2019-05-02 17:29:37 +00:00
Nico Weber d5c04860c1 Revert r359717, "Make check-clang depend on the clang-check binary always"
The Tooling tests do have a lit.local.cfg with

    if not config.root.clang_staticanalyzer:
        config.unsupported = True

so what's wrong isn't the missing dep, but that lit prints a warning for
the binary missing. This will need a different kind of fix.

llvm-svn: 359739
2019-05-01 23:32:38 +00:00
Nico Weber 18add160c2 Make check-clang depend on the clang-check binary always
check-clang (the target that runs all clang tests) used to
only depend on clang-check (a binary like clang-tidy,
clang-refactor, etc) if the static analyzer is enabled.
However, several lit tests call clang-check unconditionally,
so always depend on it.

Fixes a "could not find clang-check" lit warning in clean builds with
the static analyzer disabled.

Also sort the deps in the CMake file and put just one dep on each line.

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

llvm-svn: 359717
2019-05-01 19:34:00 +00:00
Hubert Tong 66a9642f56 [lit][tests][AIX] Update expected form of diagnostic messages; use `not` to normalize non-zero exit values
Summary:
Various tests in the `lit` testing suite expect specific return codes
and forms of diagnostic message from utility programs. As per
POSIX.1-2017 XCU Section 1.4, Utility Description Defaults, "[the]
format of diagnostic messages for most utilities is unspecified".
The STDERR subsections of the `cat` and `wc` utilities merely indicate
that "[the] standard error shall be used only for diagnostic messages".
The corresponding EXIT STATUS subsections merely indicate, with regard
to errors, an exit value of >0.

The affected tests are updated to accept the applicable diagnostic
message as produced by the utilities on AIX. The exit value is
normalized using `not` as necessary.

Reviewers: xingxue, sfertile, jasonliu

Reviewed By: xingxue

Subscribers: delcypher, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 359690
2019-05-01 15:47:16 +00:00
Nico Weber 2408736d48 gn build: Fix build on macOS after r359570 / r359527
llvm-svn: 359637
2019-04-30 23:40:58 +00:00
Nico Weber bc5fff32d4 gn build: Merge r359626
llvm-svn: 359635
2019-04-30 23:22:40 +00:00
Nico Weber 2e78c5a883 gn build: Add check-clangd target after r3359424
r359527 already merged some of that to the GN build,
but it was missing some bits as well.

The check-clangd target works (at least for now) differently than all
the other check-foo targets, see https://reviews.llvm.org/D61187

For that reason, there's no gni file and the generated lit configs are
not (yet?) added to llvm-lit/BUILD.gn.

llvm-svn: 359570
2019-04-30 15:36:02 +00:00
Nico Weber 5c45094eaa gn build: Merge r359455
llvm-svn: 359562
2019-04-30 13:45:16 +00:00
Vitaly Buka d1e87d41cb [clangd] Fix GN build
llvm-svn: 359527
2019-04-30 01:35:42 +00:00
Nico Weber 8c474a38d1 gn build: Merge r359252
llvm-svn: 359514
2019-04-29 23:06:03 +00:00
Martin Storsjo 6da0989cc4 [UpdateTestChecks] Allow Lbegin_func without a leading period
On mingw/i686, local labels don't start with a leading period.

Also escape the leading period, as it previously could match
any char.

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

llvm-svn: 359497
2019-04-29 20:25:56 +00:00
Petr Hosek 4972164871 [gn] Use label_name rather than target_output_name for objects
Multiple targets in the same output directory can use the same
target_output_name. The typical example of that is having a shared
and a static library of the same, e.g. libc++.so and libc++.a.
When that's the case, the object files produced for each target
are going to conflict. Using the label_name avoids this conflict
since labels are guaranteed to be unique within a single BUILD.gn
file which corresponds to a single output directory.

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

llvm-svn: 359494
2019-04-29 20:04:20 +00:00
Simon Pilgrim 41232d2661 [TableGen] Fix null pointer dereferencing.
Reported in https://www.viva64.com/en/b/0629/

llvm-svn: 359474
2019-04-29 17:41:27 +00:00
Hans Wennborg 1536717733 gn: Fix check-clang build after r359179
llvm-svn: 359429
2019-04-29 09:58:48 +00:00
Nico Weber a506fab189 gn build: Document llvm_enable_dia_sdk variable better
llvm-svn: 359196
2019-04-25 14:56:56 +00:00
Nico Weber 5d22bcbb78 gn build: Make setting llvm_enable_dia_sdk=true work
If this is set, %INCLUDE% must contain ".../DIA SDK/include"
and %LIB% must contain ".../DIA SKD/lib/amd64" (assuming you're doing a
64-bit build).

llvm-svn: 359195
2019-04-25 14:53:53 +00:00
Nico Weber 98b0c910fb gn build: Merge r359179
llvm-svn: 359189
2019-04-25 13:29:34 +00:00
Nico Weber 7b37559b5d gn build: Merge r359174
llvm-svn: 359188
2019-04-25 13:26:54 +00:00
Nico Weber 0f85875a9b gn build: Merge r359142
llvm-svn: 359187
2019-04-25 13:25:00 +00:00
Davide Italiano 4f88388c0b [utils] Add a lldb data formatter for llvm::SmallString.
Result:

(lldb) p val
(llvm::SmallString<32>) $31 = "patatino"

llvm-svn: 359157
2019-04-25 00:03:02 +00:00
Nico Weber 95c18c7bee gn build: Merge r359050 more
llvm-svn: 359058
2019-04-24 00:59:24 +00:00
Nico Weber 8b83fb590d gn build: Merge r359050
llvm-svn: 359056
2019-04-24 00:44:14 +00:00
Fangrui Song efd94c56ba Use llvm::stable_sort
While touching the code, simplify if feasible.

llvm-svn: 358996
2019-04-23 14:51:27 +00:00
Nico Weber 9fc422830a gn build: Merge r358944
llvm-svn: 358993
2019-04-23 14:32:18 +00:00
Nico Weber d7a748a71b gn build: Merge r358949
llvm-svn: 358991
2019-04-23 14:31:15 +00:00
Nico Weber 5828421c7c gn build: Merge r358869
llvm-svn: 358912
2019-04-22 19:25:40 +00:00
Nico Weber 584e7486ab gn build: Re-run `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`
llvm-svn: 358862
2019-04-21 20:14:21 +00:00
Nico Weber 01efcc61ea gn build: Merge r358749
Since the symlinks list for llvm-symbolizer is now never empty,
the :symlinks target no longer needs an explicit dep on :llvm-symbolizer
-- there will be at least one dep on a symlink, and each symlink depends
on :llvm-symbolizer already.

Since llvm-symbolizer:symlinks now produces symlinks that check-llvm
uses, make llvm/test depend on the symlink target.

llvm-svn: 358861
2019-04-21 20:08:45 +00:00
Nico Weber 684fe014df gn build: Merge r358818 (JITLink)
llvm-svn: 358860
2019-04-21 19:45:37 +00:00
Nico Weber f985e31254 gn build: Fix build after r358837
llvm-svn: 358851
2019-04-21 14:07:13 +00:00
Petr Hosek 33b996408f [gn] Move Features.inc to clangd, create a config for it
ClangdLSPServer and clangd unittests now include Features.inc so we
need to append the target_gen_dir that contains it to their
include_dirs. To do so, we use a public config that's applied to
any target that depends on the features one.

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

llvm-svn: 358837
2019-04-21 01:09:15 +00:00
Vitaly Buka a9c2ba3fff Update GN files to build with r358103
llvm-svn: 358790
2019-04-19 22:27:50 +00:00
Petr Hosek 45fc90326a [gn] Support dots in CMake paths in the sync script
Some file paths use dots to pick up sources from parent directories.

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

llvm-svn: 358774
2019-04-19 18:29:17 +00:00
Nico Weber e579800b84 gn build: Merge r358722
llvm-svn: 358755
2019-04-19 13:18:41 +00:00
Nico Weber ea622ef43e gn build: Merge r358691
llvm-svn: 358754
2019-04-19 13:16:26 +00:00
Nico Weber 52c0f55d61 gn build: Merge r358607
llvm-svn: 358670
2019-04-18 14:27:38 +00:00
Nico Weber 7a22418a1d gn build: Merge r358633
llvm-svn: 358669
2019-04-18 14:26:52 +00:00
Nico Weber a0bacc312e gn build: Merge r358620
llvm-svn: 358668
2019-04-18 14:25:45 +00:00
Nico Weber 272f15abc3 gn build: Merge r358554
llvm-svn: 358578
2019-04-17 13:40:57 +00:00
Dmitri Gribenko b9b35fd12d Fixed error message printing in write_cmake_config.py
Summary:
Previously, write_cmake_config.py would raise an error while printing
the error, because `leftovers` in "'\n'.join(leftovers)" is a tuple.

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

llvm-svn: 358557
2019-04-17 06:11:27 +00:00
Nico Weber 1ddf334ca0 gn build: Merge r358422
llvm-svn: 358486
2019-04-16 12:54:43 +00:00
Nico Weber abcade08b5 gn build: Merge r358390
llvm-svn: 358397
2019-04-15 11:25:23 +00:00
Simon Tatham 301ed1cb49 [TableGen] Include schedule model name in diagnostic.
If you have more than one schedule model in your TableGen target
definitions, then the diagnostic "No schedule information for
instruction 'foo'" is rather unhelpful, because it doesn't tell you
_which_ schedule model is missing the necessary information (or, as it
might be, missing the UnsupportedFeatures definition that would stop
it thinking it needed it).

Extended the message to include the name of the schedule model that
it's complaining about.

Reviewers: nhaehnle, hfinkel, javedabsar, efriedma, javed.absar

Reviewed By: javed.absar

Subscribers: javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 358389
2019-04-15 10:06:26 +00:00
Nico Weber 274f305a41 gn build: Merge r358297
llvm-svn: 358366
2019-04-14 23:23:14 +00:00
Nico Weber 6de31be67e gn build: Merge r358243
llvm-svn: 358365
2019-04-14 23:21:58 +00:00
Nico Weber ce1452ad27 gn build: Merge r358272
llvm-svn: 358364
2019-04-14 23:19:32 +00:00
Michal Gorny 3ec58c4ef6 [llvm] [lit] Add target-x86* features
Add a 'target-x86' and 'target-x86_64' feature sthat indicates that
the default target is 32-bit or 64-bit x86, appropriately.  Combined
with 'native' feature, we're going to use this to control x86-specific
LLDB native process tests.

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

llvm-svn: 358177
2019-04-11 14:58:39 +00:00
Roman Lebedev 5d9f656bb7 [TableGen] Introduce !listsplat 'binary' operator
Summary:
```
``!listsplat(a, size)``
    A list value that contains the value ``a`` ``size`` times.
    Example: ``!listsplat(0, 2)`` results in ``[0, 0]``.
```

I plan to use this in X86ScheduleBdVer2.td for LoadRes handling.

This is a little bit controversial because unlike every other binary operator
the types aren't identical.

Reviewers: stoklund, javed.absar, nhaehnle, craig.topper

Reviewed By: javed.absar

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358117
2019-04-10 18:26:36 +00:00
Roman Lebedev 163157378e [kate] Add '!mul' operator that was introduced in D58775
llvm-svn: 358116
2019-04-10 18:26:23 +00:00
Nico Weber af5834596b gn build: Fix Windows builds after r357797
llvm-svn: 358004
2019-04-09 14:02:02 +00:00
Craig Topper e043dadcad [X86] Remove check on isAsmParserOnly from EVEX2VEX tablegenerator. NFCI
There are no instructions VEX or EVEX instructions that set this field.

llvm-svn: 357973
2019-04-09 07:40:19 +00:00
Craig Topper 53ee783c6e [X86] Have EVEX2VEX tablegenerator use HasVEX_L and HasEVEX_L2 fields instead of the composite EVEX_LL field. Remove the EVEX_LL field. NFCI
The composite existed to simplify some other tablegen code and not really in an
important way. Remove the combined field and just calculate the vector size
using two ifs.

llvm-svn: 357972
2019-04-09 07:40:14 +00:00
Craig Topper f19f991b7f [X86] Use VEX_WIG for VPINSRB/W and VPEXTRB/W to match what is done for EVEX.
The instruction's document this as W0 for the VEX encoding. But there's a
footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX
encoding description says the VEX.W bit is ignored for instructions that are
equivalent to a legacy SSE instruction that uses REX.W to select a GPR which
would apply here.

By making this match EVEX we can remove a special case of allowing EVEX2VEX to
turn an EVEX.WIG instruction into VEX.W0.

llvm-svn: 357971
2019-04-09 07:40:10 +00:00
Craig Topper 2f9c1732b8 [X86] Split the VEX_WPrefix in X86Inst tablegen class into 3 separate fields with clear meanings.
llvm-svn: 357970
2019-04-09 07:40:06 +00:00
Nico Weber b743b45ebf gn build: Merge r357905
llvm-svn: 357907
2019-04-08 12:43:46 +00:00
Nico Weber c83ef47c63 gn-build: Re-run `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`
llvm-svn: 357906
2019-04-08 12:42:37 +00:00
Petr Hosek bcb29cb748 [gn] Support for per-target runtime directory layout
This change also introduces the clang_enable_per_target_runtime_dir
to enable the use of per-target runtime directory layout which is the
equivalent of LLVM_ENABLE_PER_TARGET_RUNTIME_DIR CMake option.

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

llvm-svn: 357850
2019-04-06 23:05:56 +00:00
Nico Weber ad8d06b687 gn build: Pacify `gn format`
llvm-svn: 357830
2019-04-05 23:57:10 +00:00
Petr Hosek 40442658db [gn] Support for building compiler-rt builtins
This is support for building compiler-rt builtins, The library build
should be complete for a subset of supported platforms, but not all
CMake options have been replicated in GN.

We always use the just built compiler to build all the runtimes, which
is equivalent to the CMake runtimes build. This simplifies the build
configuration because we don't need to support arbitrary host compiler
and can always assume the latest Clang. With GN's toolchain support,
this is significantly more efficient than the CMake runtimes build.

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

llvm-svn: 357821
2019-04-05 21:30:40 +00:00
Craig Topper 80aa2290fb [X86] Merge the different Jcc instructions for each condition code into single instructions that store the condition code as an operand.
Summary:
This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between Jcc instructions and condition codes.

Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser.

Reviewers: spatel, lebedev.ri, courbet, gchatelet, RKSimon

Reviewed By: RKSimon

Subscribers: MatzeB, qcolombet, eraman, hiraditya, arphaman, llvm-commits

Tags: #llvm

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

llvm-svn: 357802
2019-04-05 19:28:09 +00:00
Craig Topper 7323c2bf85 [X86] Merge the different SETcc instructions for each condition code into single instructions that store the condition code as an operand.
Summary:
This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between SETcc instructions and condition codes.

Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser.

Reviewers: andreadb, courbet, RKSimon, spatel, lebedev.ri

Reviewed By: andreadb

Subscribers: hiraditya, lebedev.ri, llvm-commits

Tags: #llvm

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

llvm-svn: 357801
2019-04-05 19:27:49 +00:00
Craig Topper e0bfeb5f24 [X86] Merge the different CMOV instructions for each condition code into single instructions that store the condition code as an immediate.
Summary:
Reorder the condition code enum to match their encodings. Move it to MC layer so it can be used by the scheduler models.

This avoids needing an isel pattern for each condition code. And it removes
translation switches for converting between CMOV instructions and condition
codes.

Now the printer, encoder and disassembler take care of converting the immediate.
We use InstAliases to handle the assembly matching. But we print using the
asm string in the instruction definition. The instruction itself is marked
IsCodeGenOnly=1 to hide it from the assembly parser.

This does complicate the scheduler models a little since we can't assign the
A and BE instructions to a separate class now.

I plan to make similar changes for SETcc and Jcc.

Reviewers: RKSimon, spatel, lebedev.ri, andreadb, courbet

Reviewed By: RKSimon

Subscribers: gchatelet, hiraditya, kristina, lebedev.ri, jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 357800
2019-04-05 19:27:41 +00:00
Petr Hosek d77fd4d4a1 [gn] Rebase paths in symlink_or_copy against root_build_dir
We should be always rebasing paths against root_build_dir which is
the directory where scripts are run from, not root_out_dir which is
the current toolchain directory. The latter can result in invalid
paths when the action is being used from a non-default toolchain.

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

llvm-svn: 357798
2019-04-05 19:13:54 +00:00
Petr Hosek 60d3a6224b [gn] Make -no-exceptions flag a config
This allows it to be disabled for targets that need exceptions
like libunwind, libc++abi and libc++.

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

llvm-svn: 357797
2019-04-05 19:12:37 +00:00
Saleem Abdulrasool 50e609611c lit: make rm python 3 friendly (NFC)
Add some alterations for python 3 compatibility.

llvm-svn: 357789
2019-04-05 18:00:49 +00:00
Nico Weber 226a9b96a7 gn build: Merge 357768 and 357770
llvm-svn: 357783
2019-04-05 17:05:54 +00:00
Nico Weber fbe13ccd67 gn build: Merge r357719
llvm-svn: 357781
2019-04-05 16:57:34 +00:00
Saleem Abdulrasool d3a85a26b6 lit: support long paths on Windows
Use ctypes to call into SHFileOperationW with the extended NT path to allow us
to remove paths which exceed 261 characters on Windows. This functionality is
exercised by swift's test suite.

llvm-svn: 357778
2019-04-05 16:48:00 +00:00
Nico Weber 3afc733e41 gn build: Merge r357663
llvm-svn: 357666
2019-04-04 02:08:10 +00:00
Reid Kleckner cfdd0cb5d9 [gn] Use "$link /lib" for archives instead of lib.exe
Summary:
This avoids the need to talk about lib.exe or llvm-lib.exe and it does
the right thing with LLD.

Reviewers: thakis

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 357660
2019-04-04 00:31:19 +00:00
Nico Weber fd47bc672a gn build: Add build file for dexp
None of check-clang-tools's tests run this, but the CMake
check-clang-tools depends on the binary, so add it for consistency.

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

llvm-svn: 357624
2019-04-03 19:09:15 +00:00
Nico Weber fee435702d gn build: Add build files for clangd xpc framework code
This is a bit of a larger change since this is the first (and as far as
I can tell only) place where the LLVM build produces macOS framework
bundles.

GN has some built-in support for this, so use that.
`gn help create_bundle` has a terse description (but it's a bit
outdated: `deps` must be `public_deps` and the conditionals in the
example in the help aren't quite right on non-iOS).

We need a new 'copy_bundle_data' tool, and since we copy the clangd.xpc
bundle as bundle_data into ClangdXPC.framework it needs to be able to
handle directories in addition to files.

GN also insists we have a compile_xcassets tool even though it's not
used. I just made that run `false`.

Despite GN's support for bundles, we still need to manually create the
expected symlink structure in the .framework bundle. Since this code
never runs on Windows, it's safe to create the symlinks before the
symlink targets exist, so we can just make the bundle depend on the
steps that create the symlinks. For this to work, change the symlink
script to create the symlink's containing directory if it doesn't yet
exist.

I locally verified that CMake and GN build create the same bundle
structure. (I noticed that both builds set LC_ID_DYLIB to the pre-copy
libClangdXPCLib.dylib name, but that seems to not cause any issues and
it happens in the CMake build too.)

(Also add an error message to clangd-xpc-test-client for when loading
the dylib fails – this was useful while locally debugging this.)

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

llvm-svn: 357574
2019-04-03 12:33:19 +00:00
Craig Topper b64f915ae0 [TableGen] Properly calculate the minimum size needed or ConvertFn in GenAsmmatcher.inc files
We were using the number of Matchables rather than the number of rows in the converter table.

This only matters for a few of the targets where the number of matchables is more than 255, but the number of converters is less than 255. Many of the targets have more than 256 converters. So already required a uint16_t.

llvm-svn: 357527
2019-04-02 20:52:04 +00:00
Rainer Orth 010982f750 [FileCheck] Fix FileCheck.cpp compilation on Solaris
Both LLVM 8.0.0 and current trunk fail to compile on Solaris with GCC 8.1.0:

  /vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp: In function ‘void DumpAnnotatedInput(llvm::raw_ostream&, const llvm::FileCheckRequest&, llvm::StringRef, std::vector<InputAnnotation>&, unsigned int)’:
  /vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp:408:41: error: call of overloaded ‘log10(unsigned int&)’ is ambiguous
     unsigned LineNoWidth = log10(LineCount) + 1;
                                           ^
  In file included from /vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/math.h:24,
                   from /vol/gcc-8/include/c++/8.1.0/cmath:45,
                   from /vol/llvm/src/llvm/dist/include/llvm-c/DataTypes.h:28,
                   from /vol/llvm/src/llvm/dist/include/llvm/Support/DataTypes.h:16,
                   from /vol/llvm/src/llvm/dist/include/llvm/ADT/Hashing.h:47,
                   from /vol/llvm/src/llvm/dist/include/llvm/ADT/ArrayRef.h:12,
                   from /vol/llvm/src/llvm/dist/include/llvm/Support/CommandLine.h:22,
                   from /vol/llvm/src/llvm/dist/utils/FileCheck/FileCheck.cpp:18:
  /vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:209:21: note: candidate: ‘long double std::log10(long double)’
    inline long double log10(long double __X) { return __log10l(__X); }
                       ^~~~~
  /vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:170:15: note: candidate: ‘float std::log10(float)’
    inline float log10(float __X) { return __log10f(__X); }
                 ^~~~~
  /vol/gcc-8/lib/gcc/i386-pc-solaris2.11/8.1.0/include-fixed/iso/math_iso.h:70:15: note: candidate: ‘double std::log10(double)’
   extern double log10 __P((double));
                 ^~~~~

Fixed by using std::log10 instead, which allowed the compilation on i386-pc-solaris2.11
and sparc-sun-solaris2.11 to continue.

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

llvm-svn: 357509
2019-04-02 18:38:23 +00:00
Nico Weber 709ee69d0a gn build: Merge r357469
llvm-svn: 357477
2019-04-02 14:44:34 +00:00