Disallow this meaningless combination. Doing so simplifies analysis
of LLVM code w.r.t t DLL storage-class, and prevents mistakes with
DLL storage class.
- Change the assembler to reject DLL storage class on symbols with
local linkage.
- Change the bitcode reader to clear the DLL Storage class when the
linkage is local for auto-upgrading
- Update LangRef.
There is an existing restriction on non-default visibility and local
linkage which this is modelled on.
Differential Review: https://reviews.llvm.org/D134784
This change sets
-amdgpu-assume-{external-call-stack-size | dynamic-stack-object-size}
options to zero by default for code object v5 and later. The runtime is
expected to adjust the scratch size if the amdhsa_uses_dynamic_stack bit
in the kernel descriptor is set.
Differential Revision: https://reviews.llvm.org/D128346
This adds an `instruction-count` command to llvm-remarkutil.
```
llvm-remarkutil instruction-count --parser=<bitstream|yaml> <file>
```
This will, for now, only print out asm-printer `InstructionCount` remarks.
Frequently I need to find out things like "what are the top 10 largest
functions" in a given project.
This makes it so we can find that information quickly and easily from any
format of remarks.
I chose a CSV because I usually want to stick these into a spreadsheet, and
the data is two-dimensional.
In the future, we may want to change this to another format if we add more
complicated data.
Differential Revision: https://reviews.llvm.org/D134765
We are already using the Co-author-by git tag, but don't have documentation in
our developer policy about it. Fix that.
Differential Revision: https://reviews.llvm.org/D134740
Previous commit 8b00b24f85 missed to add `int_ceil` anchor for the
llvm.ceil.* section under LangRef.rst
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D134586
It allows finding all intervals that overlap with any given point.
At this time, it does not support any deletion or rebalancing
operations.
The IntervalTree is designed to be set up once, and then queried
without any further additions.
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125776
Add vp.maxnum and vp.minnum which are vector predicted intrinsics of llvm.maxnum
and llvm.minnum.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D134639
These directives define per-test lit substitutions. The concept was
discussed at
<https://discourse.llvm.org/t/iterating-lit-run-lines/62596/10>.
For example, the following directives can be inserted into a test file
to define `%{cflags}` and `%{fcflags}` substitutions with empty
initial values, which serve as the parameters of another newly defined
`%{check}` substitution:
```
// DEFINE: %{cflags} =
// DEFINE: %{fcflags} =
// DEFINE: %{check} = %clang_cc1 %{cflags} -emit-llvm -o - %s | \
// DEFINE: FileCheck %{fcflags} %s
```
The following directives then redefine the parameters before each use
of `%{check}`:
```
// REDEFINE: %{cflags} = -foo
// REDEFINE: %{fcflags} = -check-prefix=FOO
// RUN: %{check}
// REDEFINE: %{cflags} = -bar
// REDEFINE: %{fcflags} = -check-prefix=BAR
// RUN: %{check}
```
Of course, `%{check}` would typically be more elaborate, increasing
the benefit of the reuse.
One issue is that the strings `DEFINE:` and `REDEFINE:` already appear
in 5 tests. This patch adjusts those tests not to use those strings.
Our prediction is that, in the vast majority of cases, if a test
author mistakenly uses one of those strings for another purpose, the
text appearing after the string will not happen to have the syntax
required for these directives. Thus, the test author will discover
the mistake immediately when lit reports the syntax error.
This patch also expands the documentation on existing lit substitution
behavior.
Reviewed By: jhenderson, MaskRay, awarzynski
Differential Revision: https://reviews.llvm.org/D132513
This extension does not appear to be on its way to ratification.
Out of the unratified bitmanip extensions, this one had the
largest impact on the compiler.
Posting this patch to start a discussion about whether we should
remove these extensions. We'll talk more at the RISC-V sync meeting this
Thursday.
Reviewed By: asb, reames
Differential Revision: https://reviews.llvm.org/D133834
This implements experimental support for the Zawrs extension as specified here: https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf. Despite the 1.0 version name, this has not been ratified and there was a major change to proposed specification between rc2 and rc3. Once this is ratified, it'll move out of experimental status.
This change adds assembly support, but does not include C language or IR intrinsics. We can decide if we want them, and handle that in a separate patch.
Differential Revision: https://reviews.llvm.org/D133443
Summary:
according nm in AIX OS , https://www.ibm.com/docs/en/aix/7.2?topic=n-nm-command
In AIX OS, The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes nm to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
In non AIX OS. The default is to process all support object files. and not support the OBJECT_MODE environment variable.
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D132494
Adds a design document for implementing the SME ABI in LLVM. This document
can be used as a reference for follow-up patches that attempt to implement
the ABI.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D131562
-opt-bisect-print-ir-path=foo will dump the IR to foo when opt-bisect-limit starts skipping passes.
Currently we don't print the IR if the opt-bisect-limit is higher than the total number of times opt-bisect is called.
This makes getting the IR right before a bad transform easier.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D133809
This adds llvm-remarkutil. This is intended to be a general tool for doing stuff
with/to remark files.
This patch gives it the following powers:
* `bitstream2yaml` - To convert bitstream remarks to YAML
* `yaml2bitstream` - To convert YAML remarks to bitstream remarks
These are both implemented as subcommands, like
`llvm-remarkutil bitstream2yaml <input_file> -o -`
I ran into an issue where I had some bitstream remarks coming from CI, and I
wanted to be able to do stuff with them (e.g. visualize them). But then I
noticed we didn't have any tooling for doing that, so I decided to write this
thing.
Being able to output YAML as a start seemed like a good idea, since it
would allow people to reuse any tooling they may have written based around YAML
remarks.
Hopefully it can grow into a more featureful remark utility. :)
Currently there are is an outstanding performance issue (see the TODO) with
the bitstream2yaml case. I decided that I'd keep the tool small to start with
and have the yaml2bitstream and bitstream2yaml cases be symmetric.
Also I moved the remarks documentation to its own header because it seems
a little out of place with "basic commands" and "developer tools"; it's
really kind of its own thing.
Differential Revision: https://reviews.llvm.org/D133646
The inline code in the description of `DW_OP_LLVM_arg` wasn't terminating
correctly, leading to more text displayed as code than intended. This fixes that
up and adds a superscript as a tiny embellishment.
Should have no effect on the online documentation, but it makes offline
builds more self-contained. With relative links however we have to
abstain from using `:manpage:` outside of man page cross-references.
Reviewed By: mysterymath
Differential Revision: https://reviews.llvm.org/D132794
This is based on a somewhat subjective review of the in-tree support, and where I thought further work was needed before I'd consider these "done". See the review for some discussion around what is left in terms of pattern matching.
Differential Revision: https://reviews.llvm.org/D133373
Sorry, there's no real theme to this. It's simply the rest of the extensions we implement which don't need individual discussion.
Differential Revision: https://reviews.llvm.org/D133529
This adds a description of the currently existing experimental extensions. I took all information about versions and specifications from either the original commits, or current code. I'm not terribly familiar with any of these, so double checking my facts is much appreciated.
Differential Revision: https://reviews.llvm.org/D133214
Yeting Kuo