12 Commits

Author SHA1 Message Date
Shao-Ce SUN
aff3e68d6f
[LLVM][tools] Remove unnecessary newline from error message (#120037)
The previous missing a newline:
```shell
$ llc --mattr=help
llc: error: unable to get target for 'unknown', see --version and --triple.$
```
2024-12-16 17:45:58 +08:00
Fangrui Song
e9c851484b [MC] Remove unnecessary isVerboseAsm from createAsmTargetStreamer 2024-07-21 10:33:50 -07:00
Fangrui Song
8f14e39e59 [MC] Remove unnecessary isVerboseAsm from Target::AsmTargetStreamerCtorTy
The parameter is confusing as it duplicates MCStreamer::isVeboseAsm
(initialized from MCTargetOptions::AsmVerbose). After
233cca169237b91d16092c82bd55ee6a283afe98, no in-tree target uses the
parameter.
2024-07-21 10:19:17 -07:00
Fangrui Song
867faeec05 [MC] Migrate to createAsmStreamer without unused bool parameters
In bolt/lib/Passes/AsmDump.cpp, the MCInstPrinter is created with false
AsmVerbose. The AsmVerbose argument to createAsmStreamer is unused.

Deprecate the legacy Target::createAsmStreamer overload, which might be
used by downstream.
2024-07-21 09:44:16 -07:00
Fangrui Song
9e69e6b8c3 [MC] createAsmStreamer: add overload without unused bool parameters
The bool parameters have been made ineffective in favor of
MCTargetOptions options to resolve inconsistency issues. New clients
should not pass the unused bool arguments. The existing overload will be
removed.
2024-07-20 23:28:31 -07:00
Fangrui Song
d69eb7b7ff [MC] Move createMC{Object,Asm}Streamer to .cpp
Currently, the template arguments are incomplete types and unique_ptr&&
has to be used. Moving the implementation to .cpp allows us to
use complete types and unique_ptr.

In addition, add a createMCObjectStreamer overload without unused bool
parameters. The existing createMCObjectStreamer overload, with unused
and confusing bool parameters, will be deprecated.
2024-07-20 20:59:26 -07:00
Alex Richardson
696eb3a55a Remove unnecessary newline from error message
I was writing a test that included this error and noticed the spurios
newline that made writing the test more awkward.
2023-10-26 12:07:37 -07:00
Ondrej Sykora
5a1de14067 Replace const std::string& with StringRef in TargetRegistry APIs; NFC
Differential Revision: https://reviews.llvm.org/D147592
2023-05-21 09:52:21 -04:00
Archibald Elliott
142aa1bdd1 [Support] Move Target/CPU Printing out of CommandLine
This change is rather more invasive than intended. The main intention
here is to make CommandLine.cpp not rely on llvm/Support/Host.h. Right
now, this reliance is only in 3 superficial places:
- Choosing how to expand response files (in two places)
- Printing the default triple and current CPU in `--version` output.

The built in version system has a method for adding "extra version
printers", commonly used by several tools (such as llc) to report the
registered targets in the built version of LLVM. It was reasonably easy
to move the logic for printing the default triple and current CPU into
a similar function, and register it with any relevant binaries.

The incompatible change here is that now, even if
LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO is defined, most binaries
will no longer print out the default target triple and cpu when provided
with `--version`, for instance llvm-as and llvm-dis. This breakage is
intended, but the changes in this patch keep printing the default target
and detected in `llc` and `opt` as these were remarked as important
binaries in the LLVM install.

The change to expanding response files may also be controversial, but I
believe that these macros should correspond exactly to the host triple
introspection used before.

Differential Revision: https://reviews.llvm.org/D137837
2022-12-20 09:56:14 +00:00
Matt Arsenault
752c9122a6 TargetRegistry: Don't add "error" to error messages
Many of the users of this add their own "error:" to the start,
resulting in error: error.
2022-04-19 22:29:16 -04:00
Kazu Hirata
ccdd5bb2c2 [llvm] Use range-based for loops (NFC) 2021-12-09 09:37:29 -08:00
Reid Kleckner
89b57061f7 Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454
2021-10-08 14:51:48 -07:00