1313 Commits

Author SHA1 Message Date
Tarun Prabhu
01d233ff40
Revert "[clang][flang] Support -time in both clang and flang"
Reverts llvm/llvm-project#109165

This created a buildbot failure on
[Fuchsia](https://lab.llvm.org/buildbot/#/builders/11/builds/8080).
2024-11-12 17:08:02 -07:00
Tarun Prabhu
f5396748c7
[clang][flang] Support -time in both clang and flang
The -time option prints timing information for the subcommands
(compiler, linker) in a format similar to that used by gcc/gfortran.

This partially addresses requests from #89888
2024-11-12 14:27:22 -07:00
Jaime González
52624d77c9
[clang] Check '-Wp,' arg has values before accesing (#113677)
Executing `clang -Wp,` without any argument value causes Undefined
Behavior due to accessing a SmallVector without elements

Executing clang in debug mode raises an assert and Valgrind complains as
follow:

```
$ valgrind bin/clang -Wp,
==18620== Memcheck, a memory error detector
==18620== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==18620== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==18620== Command: bin/clang -Wp,
==18620== 
==18620== Conditional jump or move depends on uninitialised value(s)
==18620==    at 0x44F215B: clang::driver::Driver::TranslateInputArgs(llvm::opt::InputArgList const&) const (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620==    by 0x4515831: clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620==    by 0x10B3435: clang_main(int, char**, llvm::ToolContext const&) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620==    by 0xF78F99: main (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== 
...
```
2024-11-05 11:41:49 -05:00
Alex Voicu
dc62edf105
[clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete offload-archs. (#113509)
This removes the temporary ban on mixing AMDGCN flavoured SPIR-V and
concrete targets (e.g. `gfx900`) in the same HIPAMD compilation. This is
done primarily by tweaking the effective / observable triple when the
target is `amdgcnspirv`, which seamlessly composes with the existing
infra. The test is stolen from #75357.
2024-11-05 10:53:05 +02:00
Zhaoshi Zheng
80a49487e1
[clang][Driver] Allow -fuse-lld=lld-link when lto is enabled on *windows-msvc targets (#113966)
Follow-up on https://github.com/llvm/llvm-project/pull/109607, we have a
use case on Windows-on-ARM64 where `cmake -G "Unix Makefiles"` generates
`-fuse-ld=lld-link`, which is accidentally disallowed by PR#109607.
2024-11-03 18:25:20 -08:00
Arvind Sudarsanam
eeee5a44bb
[Clang][SYCL] Introduce clang-sycl-linker to link SYCL offloading device code (Part 1 of many) (#112245)
This PR is one of the many PRs in the SYCL upstreaming effort focusing
on device code linking during the SYCL offload compilation process. RFC:
https://discourse.llvm.org/t/rfc-offloading-design-for-sycl-offload-kind-and-spir-targets/74088

In this PR, we introduce a new tool that will be used to perform device
code linking for SYCL offload kind. It accepts SYCL device objects in
LLVM IR bitcode format and will generate a fully linked device object
that can then be wrapped and linked into the host object.

A primary use case for this tool is to perform device code linking for
objects with SYCL offload kind inside the clang-linker-wrapper. It can
also be invoked via clang driver as follows:

`clang --target=spirv64 --sycl-link input.bc`

Device code linking for SYCL offloading kind has a number of known
quirks that makes it difficult to use in a unified offloading setting.
Two of the primary issues are:
1. Several finalization steps are required to be run on the fully-linked
LLVM IR bitcode to gaurantee conformance to SYCL standards. This step is
unique to SYCL offloading compilation flow.
2. SPIR-V LLVM Translator tool is an extenal tool and hence SPIR-V IR
code generation cannot be done as part of LTO. This limitation will be
lifted once SPIR-V backend is available as a viable LLVM backend.

Hence, we introduce this new tool to provide a clean wrapper to perform
SYCL device linking.

Co-Author: Michael Toguchi
Thanks

---------

Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
2024-10-31 09:39:55 -05:00
Michał Górny
387b37af1a
[LLVM] [Clang] Support for Gentoo *t64 triples (64-bit time_t ABIs) (#111302)
Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.

An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
2024-10-14 11:18:04 +00:00
Brad Richardson
06eb10dadf
[flang][driver] rename flang-new to flang (#110023)
This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.

---------

Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
2024-10-10 09:26:04 +01:00
Simon Tatham
e0df221dcf [clang][Driver] Rename "FatalError" key to "Error" in multilib.yaml (#110804)
This is a late-breaking change to #105684, suggested after the
original patch was already landed.
2024-10-07 09:32:06 +01:00
Kazu Hirata
8aa76d34ea
[Driver] Avoid repeated hash lookups (NFC) (#111225) 2024-10-05 09:49:49 -07:00
Carlo Cabrera
1682c99a88
[Clang][Driver] Support relative paths for CLANG_CONFIG_FILE_SYSTEM_DIR (#110962)
Shipping a system configuration file for Clang is useful, but it limits
the relocatability of the toolchain because it bakes in a reference to
an absolute path on the file system.

Let's fix that by allowing for `CLANG_CONFIG_FILE_SYSTEM_DIR` to be set
to a relative path, and then interpreting that relative to the location
of the driver if applicable.

This would be useful for the LLVM package we ship at Homebrew. We
currently have to bake in a `DEFAULT_SYSROOT` in order to ship a
toolchain that works out of the box on macOS. If
`CLANG_CONFIG_FILE_SYSTEM_DIR` supported relative paths, we could
replace that with a configuration file which would be easier to update
when the compiled-in `DEFAULT_SYSROOT` becomes stale (e.g. on macOS
version upgrades).

We could, of course, set `CLANG_CONFIG_FILE_SYSTEM_DIR` to an absolute
path to begin with. However, we do have users who install Homebrew into
a prefix that is different from the one used on our buildbots, so doing
this would result in a broken toolchain for those users.
2024-10-03 23:10:03 -07:00
Max Winkler
c1343a2921
[clang] [Driver] Ensure we error on lto with link.exe and target *-windows-msvc on non cl driver modes (#109607)
Similar to previous PRs I've done to change some `IsCLMode` checks to
`isWindowsMSVCEnvironment`.
I stumbled into this one accidentally last week. I did some greps and I
think this is the last one for now. All the remaining `IsCLMode` checks
are only valid for the cl driver mode.

For the `*-windows-msvc` target MSVC link.exe and lld are supported. LTO
isn't supported with MSVC link.exe and so we error when lto is enabled
but MSVC link.exe is being used. However we only error if the driver
mode is cl.
If we are using the clang driver with the `*-windows-msvc` target then
ensure an error is also emitted when LTO and MSVC link.exe are used
together.
2024-10-02 19:16:45 -07:00
Steven Perron
9f6cd56d5a
[HLSL] Use HLSLToolChain for Vulkan (#110306)
The options are not translated correctly when targeting Vulkan using the
dxc
driver mode. Resuing the translator used for HLSL.

Fixes problem 2 in https://github.com/llvm/llvm-project/issues/108567.
2024-09-30 10:26:14 -04:00
Sean Perry
97189492a1
The real option name and not the alias used is displayed in msgs when using a config file (#107613)
An example of this is the -mpure-code option. Without a config file
being used, an error message will print `-mpure-code`. But if a config
file is used, the error message will print `-mexecute-only`.
2024-09-25 10:51:55 -04:00
Prabhuk
fb78495376
Reland "[Driver] Add toolchain for X86_64 UEFI target" (#109364)
Reverts llvm/llvm-project#109340

Addressing the failed MAC Clang Driver test as part of this reland.
2024-09-20 11:16:36 -07:00
Alex Rønne Petersen
72a218056d
[llvm][Triple] Add Environment members and parsing for glibc/musl parity. (#107664)
This adds support for:

* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)

As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.

I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.

Note: I don't have commit access.
2024-09-20 08:53:03 +08:00
Prabhuk
d2df2e41ca
Revert "[Driver] Add toolchain for X86_64 UEFI target" (#109340)
Reverts llvm/llvm-project#76838

Appears to be causing failures in MAC builders. First reverting the
patch and will investigate after.
2024-09-19 15:28:07 -07:00
Prabhuk
d1335fb864
[Driver] Add toolchain for X86_64 UEFI target (#76838)
Introduce changes necessary for UEFI X86_64 target Clang driver.
Addressed the review comments originally suggested in Phabricator.

Differential Revision: https://reviews.llvm.org/D159541
2024-09-19 11:46:55 -07:00
dyung
4e09d7bc2c
Revert "[HIP] Use original file path for CUID" (#108771)
Reverts llvm/llvm-project#107734

The test modified in this commit, hip-cuid-hash.hip is failing on MacOS:
- https://lab.llvm.org/buildbot/#/builders/190/builds/5764
- https://lab.llvm.org/buildbot/#/builders/23/builds/3020
2024-09-15 09:40:55 -07:00
Yaxun (Sam) Liu
9fc789d922
[HIP] Use original file path for CUID (#107734)
to avoid being nondeterministic due to random path in distributed build.
2024-09-15 00:37:15 -04:00
Artem Belevich
4a501a4556
[CUDA/HIP] propagate -cuid to a host-only compilation. (#107483)
Right now we're bailing out too early, and `-cuid` does not get set for
the host-only compilations.
2024-09-09 11:14:41 -07:00
Simon Tatham
26bf0b4ae7
[clang][Driver] Add a custom error option in multilib.yaml. (#105684)
Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.

For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.

In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.

This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.

In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
2024-09-02 16:56:03 +01:00
Kim Gräsman
924a7d83b4
Use CLANG_RESOURCE_DIR more consistently (#103388)
When Clang is consumed as a library, the CLANG_RESOURCE_DIR definition
is not exported from the CMake system, so external clients will be
unable to compute the same resource dir as Clang itself would, because
they don't know what to pass for the optional CustomResourceDir
argument.

All call sites except one would pass CLANG_RESOURCE_DIR to
Driver::GetResourcesPath. It seems the one exception in libclang
CIndexer was an oversight.

Move the use of CLANG_RESOURCE_DIR into GetResourcesPath and remove the
optional argument to avoid this inconsistency between internal and
external clients.
2024-08-26 14:49:56 -03:00
Martin Storsjö
8ca5ff2743
Revert "[clang][driver] Fix -print-target-triple OS version for apple targets" (#104563)
This reverts llvm/llvm-project#104037 /
7227b44f928a87b5d7fb05bd1539fdfb6d4958dc.

This change had the unintended consequence of making e.g. `clang -target
armv7-windows-gnu --print-target-triple` output
`thumbv7-unknown-windows-gnu` rather than `armv7-unknown-windows-gnu`.
2024-08-16 11:38:22 +03:00
Gábor Horváth
7227b44f92
[clang][driver] Fix -print-target-triple OS version for apple targets (#104037)
The target needs to be initialized in order to compute the correct
target triple from the command line. Without initialized targets the OS
component of the triple might not reflect what would be computed by the
driver for an actual compiler invocation.

Fixes https://github.com/llvm/llvm-project/issues/61762
2024-08-15 10:04:59 +01:00
Johannes Doerfert
80525dfcde
[Offload][CUDA] Allow CUDA kernels to use LLVM/Offload (#94549)
Through the new `-foffload-via-llvm` flag, CUDA kernels can now be
lowered to the LLVM/Offload API. On the Clang side, this is simply done
by using the OpenMP offload toolchain and emitting calls to `llvm*`
functions to orchestrate the kernel launch rather than `cuda*`
functions. These `llvm*` functions are implemented on top of the
existing LLVM/Offload API.

As we are about to redefine the Offload API, this wil help us in the
design process as a second offload language.

We do not support any CUDA APIs yet, however, we could:
  https://www.osti.gov/servlets/purl/1892137

For proper host execution we need to resurrect/rebase
  https://tianshilei.me/wp-content/uploads/2021/12/llpp-2021.pdf
(which was designed for debugging).

```
❯❯❯ cat test.cu
extern "C" {
void *llvm_omp_target_alloc_shared(size_t Size, int DeviceNum);
void llvm_omp_target_free_shared(void *DevicePtr, int DeviceNum);
}

__global__ void square(int *A) { *A = 42; }

int main(int argc, char **argv) {
  int DevNo = 0;
  int *Ptr = reinterpret_cast<int *>(llvm_omp_target_alloc_shared(4, DevNo));
  *Ptr = 7;
  printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
  square<<<1, 1>>>(Ptr);
  printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
  llvm_omp_target_free_shared(Ptr, DevNo);
}

❯❯❯ clang++ test.cu -O3 -o test123 -foffload-via-llvm --offload-arch=native

❯❯❯ llvm-objdump --offloading test123

test123:        file format elf64-x86-64

OFFLOADING IMAGE [0]:
kind            elf
arch            gfx90a
triple          amdgcn-amd-amdhsa
producer        openmp

❯❯❯ LIBOMPTARGET_INFO=16 ./test123
Ptr 0x155448ac8000, *Ptr 7
Ptr 0x155448ac8000, *Ptr 42
```
2024-08-12 17:44:58 -07:00
Kazu Hirata
7a6acd9844
[clang] Use llvm::is_contained (NFC) (#102720) 2024-08-09 22:39:19 -07:00
macurtis-amd
13dd795ef1
[clang][NFC] Make OffloadLTOMode getter a separate method (#101200)
Minor readability improvement (IMHO). Also makes it easier to find the
places where we are getting the offload lto mode.
2024-08-05 10:06:51 -05:00
Gábor Horváth
7d8375b86e
[clang][driver] Fix -print-libgcc-file-name on Darwin platforms (#98325)
On Darwin, -print-libgcc-file-name was returning a nonsensical result.
It would return the name of the library that would be used by the
default toolchain implementation, but that was something that didn't
exist on Darwin.

Fixing this requires initializing the Darwin toolchain before processing
`-print-libgcc-file-name`. Previously, the Darwin toolchain would only
be initialized when building the jobs for this compilation, which is too
late since `-print-libgcc-file-name` requires the toolchain to be
initialized in order to provide the right results.

rdar://90633749

Co-authored-by: Gabor Horvath <gaborh@apple.com>
2024-07-19 13:24:38 +01:00
Michael Maitland
eee5d2d37c
[RISCV] Add ability to list extensions enabled for a target (#98207)
bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this option. This patch
adds documentation for this option.

`riscvExtensionsHelp` is renamed to `printSupportedExtensions` to by
synonymous with AArch64 and so it is clear what that function does.
2024-07-10 15:39:08 -04:00
Yingwei Zheng
9acaccbaee
[RISCV][Driver] Refactor riscv::getRISCVArch to return std::string. NFC. (#97965)
See the discussion in
https://github.com/llvm/llvm-project/pull/94352#discussion_r1657074801
2024-07-09 14:34:37 +08:00
Jakub Chlanda
ab20086422
[CUDA][NFC] CudaArch to OffloadArch rename (#97028)
Rename `CudaArch` to `OffloadArch` to better reflect its content and the
use.
Apply a similar rename to helpers handling the enum.
2024-06-30 07:56:07 +02:00
Fangrui Song
592abf29f9 [Driver] BuildOffloadingActions: Actually stabilize iteration order
In
```
/tmp/StaticDebug/bin/clang -ccc-print-phases -lsomelib -fopenmp=libomp --target=powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu clang/test/Driver/openmp-offload.c clang/test/Driver/openmp-offload.c
```

Both ToolChains have one single empty arch. llvm::sort in
LLVM_ENABLE_EXPENSIVE_CHECKS=on builds could swap the two entries.

Fixes: 255986e27fcf9f0b36f7a23fbe030fcca1ba0249
2024-06-28 11:06:29 -07:00
Lucas Duarte Prates
bb83a3df25
Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
2024-06-28 09:20:16 +01:00
Lucas Duarte Prates
b579aacc30
Revert "[AArch64] Add ability to list extensions enabled for a target" (#96768)
Reverts llvm/llvm-project#95805 due to test failures caught by the
buildbots.
2024-06-26 14:59:01 +01:00
Lucas Duarte Prates
b6240c3715
[AArch64] Add ability to list extensions enabled for a target (#95805)
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
2024-06-26 14:28:26 +01:00
Alex Voicu
9acb533c38
[clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (#95061)
This patch augments the HIPAMD driver to allow it to target AMDGCN
flavoured SPIR-V compilation. It's mostly straightforward, as we re-use
some of the existing SPIRV infra, however there are a few notable
additions:

- we introduce an `amdgcnspirv` offload arch, rather than relying on
using `generic` (this is already fairly overloaded) or simply using
`spirv` or `spirv64` (we'll want to use these to denote unflavoured
SPIRV, once we bring up that capability)
- initially it is won't be possible to mix-in SPIR-V and concrete AMDGPU
targets, as it would require some relatively intrusive surgery in the
HIPAMD Toolchain and the Driver to deal with two triples
(`spirv64-amd-amdhsa` and `amdgcn-amd-amdhsa`, respectively)
- in order to retain user provided compiler flags and have them
available at JIT time, we rely on embedding the command line via
`-fembed-bitcode=marker`, which the bitcode writer had previously not
implemented for SPIRV; we only allow it conditionally for AMDGCN
flavoured SPIRV, and it is handled correctly by the Translator (it ends
up as a string literal)

Once the SPIRV BE is no longer experimental we'll switch to using that
rather than the translator. There's some additional work that'll come
via a separate PR around correctly piping through AMDGCN's
implementation of `printf`, for now we merely handle its flags
correctly.
2024-06-25 12:19:28 +01:00
David Truby
a2d340ba16
Revert "[Flang][Driver] Add -print-resource-dir command line flag to emit Flang's resource directory" (#96557)
Reverts llvm/llvm-project#90886

These changes broke linking to compiler-rt on Windows
2024-06-25 00:46:50 +01:00
Fangrui Song
255986e27f [Driver] BuildOffloadingActions: Stabilize iteration order
Otherwise hip-phases.hip could fail when llvm::hash_value(StringRef)
changes.
2024-06-20 21:45:40 -07:00
Braden Helmer
83a54e75c1
[clang] Implement -Wmissing-include-dirs (#94827)
Implements -Wmissing-include-dirs #92015 

This is my first contribution and would love some feedback. Thanks!
2024-06-12 11:30:10 +02:00
huangqinjin
06b5a7c205
[clang][driver] Support -x for all languages in CL mode (#89772)
After https://github.com/llvm/llvm-project/pull/68921, clang-cl gained
option `-x` but only for CUDA/HIP. This commit simply removes the
restriction on parameters to `-x`. Especially, it is able to use `-x
c++-module` and `-x c++-system-header` to build C++20 modules and header
units with clang-cl.

This effectively reverts commit
fe082124faa8455cc9a68be5fdf10fc46a4d066c.

Closes https://github.com/llvm/llvm-project/issues/88006.
2024-05-23 22:39:17 -07:00
Michael Klemm
2df06e42d7
[Flang][Driver] Add -print-resource-dir command line flag to emit Flang's resource directory (#90886)
This should be a NFC change for all drivers, but Flang.
2024-05-14 09:01:51 +02:00
Kazu Hirata
135d92f903
[Driver] Use StringRef::operator== instead of StringRef::equals (NFC) (#91698)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
  13 under clang/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
  std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
  !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-09 23:12:08 -07:00
Nathan Lanza
359ab3aebb
[CIR] Add options to emit ClangIR and enable the ClangIR pipeline
Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.

Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay

Reviewed By: erichkeane

Pull Request: https://github.com/llvm/llvm-project/pull/89030
2024-04-29 15:46:18 -04:00
Craig Topper
733a87783c
[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
2024-04-23 15:12:36 -07:00
Chuanqi Xu
f811d7b509
[C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (#85050)
This is the driver part of
https://github.com/llvm/llvm-project/pull/75894.

This patch introduces '-fexperimental-modules-reduced-bmi' to enable
generating the reduced BMI.

This patch did:
- When `-fexperimental-modules-reduced-bmi` is specified but
`--precompile` is not specified for a module unit, we'll skip the
precompile phase to avoid unnecessary two-phase compilation phases. Then
if `-c` is specified, we will generate the reduced BMI in CodeGenAction
as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified and
`--precompile` is specified, we will generate the reduced BMI in
GenerateModuleInterfaceAction as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified for a
non-module unit. We don't do anything nor try to give a warn. This is
more user friendly so that the end users can try to test and experiment
with the feature without asking help from the build systems.

The core design idea is that users should be able to enable this easily
with the existing cmake mechanisms.

The future plan for the flag is:
- Add this to clang19 and make it opt-in for 1~2 releases. It depends on
the testing feedback to decide how long we like to make it opt-in.
- Then we can announce the existing BMI generating may be deprecated and
suggesting people (end users or build systems) to enable this for 1~2
releases.
- Finally we will enable this by default. When that time comes, the term
`BMI` will refer to the reduced BMI today and the existing BMI will only
be meaningful to build systems which loves to support two phase
compilations.

I'll send release notes and document in seperate commits after this get
landed.
2024-04-15 11:55:45 +08:00
Cassie Jones
68b939f931
[driver] Make --version show if assertions, etc. are enabled (#87585)
It's useful to have some significant build options visible in the
version when investigating problems with a specific compiler artifact.
This makes it easy to see if assertions, expensive checks, sanitizers,
etc. are enabled when checking a compiler version.

Example config line output:
Build configuration: +unoptimized, +assertions, +asan, +ubsan
2024-04-05 10:01:09 -07:00
Daniel Grumberg
e05c1b46d0
Reenable external categories (#87357)
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.

Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
2024-04-03 10:18:05 +01:00
Daniel Grumberg
209a1e8dfd Revert "[clang][ExtractAPI] Add ability to create multiple symbol graphs (#86676)"
This failed the test suite due to missing DiagGroup for a new warning.

This reverts commit b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
2024-04-02 15:34:52 +01:00
Daniel Grumberg
b31414bf4f
[clang][ExtractAPI] Add ability to create multiple symbol graphs (#86676)
This extends ExtractAPI to take into account symbols defined in categories to types defined in an external module.
This introduces 2 new command line flags, `--symbol-graph-dir=DIR` and `--emit-extension-symbol-graphs`, when used together this generates additional symbol graph files at `DIR/ExtendedModule@ProductName.symbols.json` for each external module that is extended in this way.

Additionally this makes some cleanups to tests to make them more resilient and cleans up the `APISet` data structure.
2024-04-02 15:03:46 +01:00