Commit Graph

1762 Commits

Author SHA1 Message Date
LLVM GN Syncbot ac6572a5c8 [gn build] Port 5fbe1fdf17 2021-03-24 19:01:21 +00:00
LLVM GN Syncbot f6259efee7 [gn build] Port 5fd001a5ff 2021-03-24 17:33:50 +00:00
Nico Weber 82fa17aad1 [gn build] (manually) port 301d9261b7
This reverts commit 50fd426fd8
and tweaks things for the reland: SystemZAsmLexer is now
SystemZAsmLexerTests.
2021-03-24 10:44:00 -04:00
Nico Weber 1ad9c95a45 [gn build] port 1d8fc086ae 2021-03-24 08:29:34 -04:00
Nico Weber ed0558a09d [gn build] (manually) port d709dcc090 2021-03-23 10:13:14 -04:00
Valentin Clement d709dcc090 [openacc][openmp] Reduce number of generated file and prefer inclusion of .inc
Follow up from D92955 and D83636. This patch makes the base cpp files
OMP.cpp and ACC.cpp normal files and they now include the XXX.inc file
generated by tablegen. This reduces the number of file generated by the
DirectiveEmitter backend and makes it closer to the proposal in D83636.

Reviewed By: Meinersbur

Differential Revision: https://reviews.llvm.org/D93560
2021-03-23 09:16:53 -04:00
LLVM GN Syncbot 308d40fe66 [gn build] Port 274907c0a4 2021-03-23 13:01:57 +00:00
Gulfem Savrun Yeniceri e3a6d70c68 Revert "[Passes] Add relative lookup table converter pass"
This reverts commit 78a65cd945 which
caused buildbot failures.
2021-03-23 00:43:16 +00:00
Nico Weber d39d526924 [gn build] fix typo in 78a65cd945 2021-03-22 18:38:17 -04:00
Gulfem Savrun Yeniceri 78a65cd945 [Passes] Add relative lookup table converter pass
Lookup tables generate non PIC-friendly code, which requires dynamic relocation as described in:
https://bugs.llvm.org/show_bug.cgi?id=45244

This patch adds a new pass that converts lookup tables to relative lookup tables to make them PIC-friendly.

Differential Revision: https://reviews.llvm.org/D94355
2021-03-22 22:09:02 +00:00
LLVM GN Syncbot ce04af87ca [gn build] Port 5a87f81fe9 2021-03-22 17:10:11 +00:00
Carl Ritson fe5f4c397f [AMDGPU] Rename SIInsertSkips Pass
Pass no longer handles skips.  Pass now removes unnecessary
unconditional branches and lowers early termination branches.
Hence rename to SILateBranchLowering.

Move code to handle returns to epilog from SIPreEmitPeephole
into SILateBranchLowering. This means SIPreEmitPeephole only
contains optional optimisations, and all required transforms
are in SILateBranchLowering.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D98915
2021-03-20 11:48:04 +09:00
Carl Ritson 5df2af8b0e [AMDGPU] Merge SIRemoveShortExecBranches into SIPreEmitPeephole
SIRemoveShortExecBranches is an optimisation so fits well in the
context of SIPreEmitPeephole.

Test changes relate to early termination from kills which have now
been lowered prior to considering branches for removal.
As these use s_cbranch the execz skips are now retained instead.
Currently either behaviour is valid as kill with EXEC=0 is a nop;
however, if early termination is used differently in future then
the new behaviour is the correct one.

Reviewed By: foad

Differential Revision: https://reviews.llvm.org/D98917
2021-03-20 11:26:42 +09:00
Peter Collingbourne eef8b74ef5 gn build: Unbreak Android cross-compilation.
- D96404 defaulted to libunwind which isn't provided by NDK r21
  (or r22), so specify -rtlib=libgcc on non-arm32.
- D97993 means that we need to use --gcc-toolchain instead of -B
  to let the driver find libgcc.
2021-03-19 16:28:24 -07:00
LLVM GN Syncbot 6333ee2184 [gn build] Port ed8bff13dc 2021-03-18 14:39:37 +00:00
LLVM GN Syncbot 70aa319ee7 [gn build] Port 9a5af541ee 2021-03-16 14:03:53 +00:00
LLVM GN Syncbot 6547dcb4f3 [gn build] Port 4f198b0c27 2021-03-16 02:41:16 +00:00
LLVM GN Syncbot 2ef6ee1978 [gn build] Port ecf6466f01 2021-03-15 23:01:19 +00:00
Nico Weber 264ff539f3 [gn build] merge af2796c76d a bit more
The default is fine on non-Win, but on Win this needs an explicit
setting now that lit no longer has the right default.
2021-03-15 18:20:54 -04:00
Nico Weber 01d648a69b [gn build] merge 9bcf0eff99 2021-03-15 17:05:05 -04:00
Nico Weber efbaf4030b [gn build] kind of merge af2796c76d
Good enough for now. If we need more, we'll do the usual
platform-dependent hardcoding that in practice works for everything else
too.
2021-03-15 17:01:00 -04:00
Nico Weber a431268668 [gn build] (semi-manually) port b136a74efc 2021-03-15 12:51:12 -04:00
LLVM GN Syncbot fd9604c815 [gn build] Port 13e49dcee4 2021-03-15 15:24:41 +00:00
Stephen Kelly 19740652c4 [AST] Add generator for source location introspection
Generate a json file containing descriptions of AST classes and their
public accessors which return SourceLocation or SourceRange.

Use the JSON file to generate a C++ API and implementation for accessing
the source locations and method names for accessing them for a given AST
node.

This new API can be used to implement 'srcloc' output in clang-query:

  http://ce.steveire.com/z/m_kTIo

The JSON file can also be used to generate bindings for other languages,
such as Python and Javascript:

  https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching

In this first version of this feature, only the accessors for Stmt
classes are generated, not Decls, TypeLocs etc.  Those can be added
after this change is reviewed, as this change is mostly about
infrastructure of these code generators.

Also in this version, the platforms/cmake configurations are excluded as
much as possible so that support can be added iteratively.  Currently a
break on any platform causes a revert of the entire feature.  This way,
the `OR WIN32` can be removed in a future commit and if it breaks the
buildbots, only that commit gets reverted, making the entire process
easier to manage.

Differential Revision: https://reviews.llvm.org/D93164
2021-03-15 10:52:44 +00:00
Stephen Kelly 6e303a982d Revert "[AST] Add generator for source location introspection"
This reverts commit 91abaa1f8d.
2021-03-15 01:16:10 +00:00
Stephen Kelly 91abaa1f8d [AST] Add generator for source location introspection
Generate a json file containing descriptions of AST classes and their
public accessors which return SourceLocation or SourceRange.

Use the JSON file to generate a C++ API and implementation for accessing
the source locations and method names for accessing them for a given AST
node.

This new API can be used to implement 'srcloc' output in clang-query:

  http://ce.steveire.com/z/m_kTIo

The JSON file can also be used to generate bindings for other languages,
such as Python and Javascript:

  https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching

In this first version of this feature, only the accessors for Stmt
classes are generated, not Decls, TypeLocs etc.  Those can be added
after this change is reviewed, as this change is mostly about
infrastructure of these code generators.

Also in this version, the platforms/cmake configurations are excluded as
much as possible so that support can be added iteratively.  Currently a
break on any platform causes a revert of the entire feature.  This way,
the `OR WIN32` can be removed in a future commit and if it breaks the
buildbots, only that commit gets reverted, making the entire process
easier to manage.

Differential Revision: https://reviews.llvm.org/D93164
2021-03-15 00:00:29 +00:00
Stephen Kelly e312b4b6c7 Revert "[AST] Add generator for source location introspection"
This reverts commit 477e4b9746.
2021-03-14 22:51:45 +00:00
Stephen Kelly 477e4b9746 [AST] Add generator for source location introspection
Generate a json file containing descriptions of AST classes and their
public accessors which return SourceLocation or SourceRange.

Use the JSON file to generate a C++ API and implementation for accessing
the source locations and method names for accessing them for a given AST
node.

This new API can be used to implement 'srcloc' output in clang-query:

  http://ce.steveire.com/z/m_kTIo

The JSON file can also be used to generate bindings for other languages,
such as Python and Javascript:

  https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching

In this first version of this feature, only the accessors for Stmt
classes are generated, not Decls, TypeLocs etc.  Those can be added
after this change is reviewed, as this change is mostly about
infrastructure of these code generators.

Also in this version, the platforms/cmake configurations are excluded as
much as possible so that support can be added iteratively.  Currently a
break on any platform causes a revert of the entire feature.  This way,
the `OR WIN32` can be removed in a future commit and if it breaks the
buildbots, only that commit gets reverted, making the entire process
easier to manage.

Differential Revision: https://reviews.llvm.org/D93164
2021-03-14 22:32:42 +00:00
Nico Weber 237526319c Revert "[gn build] (manually) kind of merge d627a27d26"
This reverts commit 5123327eda.
d627a27d26 was reverted in e0f70a8a97.
2021-03-14 12:18:22 -04:00
Nico Weber 5123327eda [gn build] (manually) kind of merge d627a27d26
This only merges the no-op generator part for now.
2021-03-14 09:19:44 -04:00
Nico Weber 50fd426fd8 Revert "[gn build] (manually) port bcdd40f802a5"
This reverts commit 0bd9d9aa3c.
bcdd40f802 was reverted in 4f9cc1512d
2021-03-12 15:04:20 -05:00
Nico Weber 0bd9d9aa3c [gn build] (manually) port bcdd40f802 2021-03-12 12:15:52 -05:00
LLVM GN Syncbot 0cb0c6beda [gn build] Port 5433a79176 2021-03-11 18:35:32 +00:00
Nico Weber cb17f060e2 [gn build] (manually) Port d6a0560bf2 2021-03-10 21:56:59 -05:00
LLVM GN Syncbot af4ae18319 [gn build] Port 4f16e177e1 2021-03-10 23:36:48 +00:00
Sriraman Tallam 0ba1ebcbb7 Remove original implementation of UniqueInternalLinkageNames pass.
D96109 was recently submitted which contains the refactored implementation of
-funique-internal-linakge-names by adding the unique suffixes in clang rather
than as an LLVM pass. Deleting the former implementation in this change.

Differential Revision: https://reviews.llvm.org/D98234
2021-03-10 11:57:40 -08:00
LLVM GN Syncbot 84fa3497c8 [gn build] Port 5c26be214d 2021-03-08 21:01:52 +00:00
LLVM GN Syncbot e1928f0e92 [gn build] Port 5eb7a5814a 2021-03-08 20:33:54 +00:00
LLVM GN Syncbot b790a15e4b [gn build] Port 5509748f2c 2021-03-08 20:33:53 +00:00
LLVM GN Syncbot bb1fe3f943 [gn build] Port 503343191e 2021-03-08 20:33:53 +00:00
Nico Weber 08c709a266 [gn build] (manually) port ebe6161c54 2021-03-08 14:56:41 -05:00
Nico Weber 98c6d3194e [gn build] allow setting clang_base_path to a source-absolute path
With this, you can set `clang_base_path = "//out/gn1"` in `out/gn2/args.gn` and
the build in out/gn2 will use clang and lld from out/gn1.

Setting `clang_base_path` to an absolute path (with e.g.
`clang_base_path = getenv("HOME") + "/src/..."`) should behave as before.

Differential Revision: https://reviews.llvm.org/D97989
2021-03-05 12:13:51 -05:00
LLVM GN Syncbot f456fd0ed8 [gn build] Port a60d06d8b7 2021-03-05 11:09:38 +00:00
Nico Weber ecdae5df7d [gn build] port b973e2e2f2 2021-03-04 18:41:04 -05:00
LLVM GN Syncbot c3960087f6 [gn build] Port 561abd83ff 2021-03-04 22:58:35 +00:00
LLVM GN Syncbot ba18a51c38 [gn build] Port d7834556b7 2021-03-04 21:34:02 +00:00
Nico Weber 4b192f8084 [gn build] port db06088d63 2021-03-04 16:33:24 -05:00
Nico Weber 4c1bf9e0ee [gn build] port e9f9ec837d 2021-03-04 11:40:12 -05:00
LLVM GN Syncbot 635db3514b [gn build] Port d791695cb5 2021-03-04 11:17:51 +00:00
Stefan Gränitz e984c2b06f Revert "hack to unbreak check-llvm on win after D97335" in attempt for actual fix
This reverts commit 900f076113 and attempts an actual fix: All failing tests for llvm-jitlink use the `-noexec` flag. The inputs they operate on are not meant for execution on the host system. Looking e.g. at the MachO_test_harness_harnesss.s test, llvm-mc generates input machine code with "x86_64-apple-macosx10.9".

My previous attempt in bbdb4c8c9b disabled the debug support plugin for Windows targets, but what we would actually want is to disable it on Windows HOSTS.

With the new patch here, I don't do exactly that, but instead follow the approach for the EH frame plugin and include the `-noexec` flag in the condition. It should have the desired effect when it comes to the test suite. It appears a little workaround'ish, but should work reliably for now. I will discuss the issue with Lang and see if we can do better. Thanks @thakis again for the temporary fix.
2021-03-03 22:35:36 +01:00