Ignore paramater declarations of type `::llvm::Twine`, These don't suffer the same use after free risks as local twines.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D82281
Add a new builtin-function __builtin_expect_with_probability and
intrinsic llvm.expect.with.probability.
The interface is __builtin_expect_with_probability(long expr, long
expected, double probability).
It is mainly the same as __builtin_expect besides one more argument
indicating the probability of expression equal to expected value. The
probability should be a constant floating-point expression and be in
range [0.0, 1.0] inclusive.
It is similar to builtin-expect-with-probability function in GCC
built-in functions.
Differential Revision: https://reviews.llvm.org/D79830
Implement shape analysis for the result of the MATMUL
generic transformational intrinsic function, based on
the shapes of its arguments. Correct the names of the
arguments to match the standard, too.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82250
Add a way to quit the interactive script interpreter from a shell tests.
Currently, the only way (that I know) to exit the interactive Lua
interpreter is to send a EOF with CTRL-D. I noticed that the embedded
Python script interpreter accepts quit (while the regular python
interpreter doesn't). I've added a special case to the Lua interpreter
to do the same.
Differential revision: https://reviews.llvm.org/D82272
Currently we stop exploring candidates too early in some cases.
In particular, we can continue checking the defining accesses of
non-removable MemoryDefs and defs without analyzable write location
(read clobbers are already ruled out using MemorySSA at this point).
This features matches ELFAsmParser and makes it possible to use `.section ".llvm.call-graph-profile","n"`
Reviewed By: zequanwu
Differential Revision: https://reviews.llvm.org/D82240
Summary:
Currently when --passes is used, any passes specified via -foo are
ignored. Explicitly bail out when that happens.
This requires changing some tests. Most were straightforward, but
codegenprepare-produced-address-math.ll is tricky. One of its RUNs runs
CodeGenPrepare. I tried porting CodeGenPrepare to the NPM, but ended up
getting stuck when I needed a TargetMachine. NPM doesn't have support
for MachineFunctions yet. So I just deleted that RUN line, since it was
mass-added in https://reviews.llvm.org/D54848 and is likely not that
useful.
Reviewers: echristo, hans
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82271
This adds the abstract converter interface. The abstract converter is an
interface that supports the conversion of front-end data structures to
MLIR. This interface will be instantiated by the bridge in a future
commit.
Differential revision: https://reviews.llvm.org/D82268
Summary:
Currently, the TableGen rewrite generates redundant native calls in MLIR DRR files. This is a problem as some native calls may involve significant computations (e.g. when performing constant propagation where every values in a large tensor is touched).
The pattern was as follow:
```c++
if (native-call(args)) tblgen_attrs.emplace_back(rewriter, attribute, native-call(args))
```
The replacement pattern compute `native-call(args)` once and then use it both in the `if` condition and the `emplace_back` call.
Differential Revision: https://reviews.llvm.org/D82101
Following on from this RFC[0] from a while back, this is the first patch towards
implementing variadic debug values.
This patch specifically adds a set of functions to MachineInstr for performing
operations specific to debug values, and replacing uses of the more general
functions where appropriate. The most prevalent of these is replacing
getOperand(0) with getDebugOperand(0) for debug-value-specific code, as the
operands corresponding to values will no longer be at index 0, but index 2 and
upwards: getDebugOperand(x) == getOperand(x+2). Similar replacements have been
added for the other operands, along with some helper functions to replace
oft-repeated code and operate on a variable number of value operands.
[0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139376.html<Paste>
Differential Revision: https://reviews.llvm.org/D81852
Summary:
Windows forbidden file path characters are used in a field `file`, while creating a dump `dot` file using an argument -analyzer-dump-egraph. It specifically relates to angle brackets when using `<scratch space>`, `<built-in>`, `<command line>` values in filenames. It causes that script exploded-graph-rewriter.py incorrectly parses the dump.
Fix:
Remove forbidden characters from filename for Windows platform, when creating graph dump file.
Differential Revision: https://reviews.llvm.org/D82103
This patch extends the AccessChainOp index type handling to be able to deal with
all Integer type indices (i.e., all bit-widths and signedness symantics).
There were two ways of achieving this:
1- Backward compatible: The new way of handling the indices will assume that
an index type is i32 by default if not specified in the assembly format,
this way all the old tests would pass correctly.
2- Enforce the format: This unifies the spv.AccessChain Op format and all the old
tests had to be updated to reflect this change or else they fail.
I picked option-2 to unify the Op format and avoid having optional index-type fields
that can lead to somewhat confusing tests format and multiple representations for
the same Op with undocumented assumption that an index is i32 unless stated.
Nonetheless, reverting to option-1 should be straightforward if preferred or needed.
Differential Revision: https://reviews.llvm.org/D81763
These operations do member-wise versions of the all of the listed
operations. This patch implements all of the binaryoperators for these
types. Note that the test is required to use codegen as I could not come
up with a good way to validate the values without the array-subscript
operator implemented (which is likely a much more involved change).
Differential Reivision: https://reviews.llvm.org/D79755
Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration between the different Frontend.
While doing this it was thought that moving to tablegen instead of Macros will also
give a cleaner and more powerful way of generating these declaration.
This first part of a future series of patches is setting up the base .td file for
DirectiveLanguage as well as the OpenMP version of it. The base file is meant to
be used by other directive language such as OpenACC.
In this first patch, the Directive and Clause enums are generated with tablegen
instead of the macros on OMPConstants.h. The next pacth will extend this
to other enum and move the Flang frontend to use it.
Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp
Reviewed By: jdoerfert, jdenny
Subscribers: cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #openmp, #clang
Differential Revision: https://reviews.llvm.org/D81736
This patch helps add support for error handling in `DWARFYAML::emitDebugInfo()`.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D82275
Before this patch, we use `(uint32_t)AbbrCode - (uint32_t)FirstAbbrCode` to index the abbreviation. It's impossible for we to use the preceeding abbreviation of the previous one (e.g., if the previous DIE's `AbbrCode` is 2, we are unable to use the abbreviation with index 1). In this patch, we use `AbbrCode` to index the abbreviation directly.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D82173
We have many cases where we call SimplifyMultipleUseDemandedBits and demand specific vector elements, but all the bits from them - this adds a helper wrapper to handle this.
Reland 90c1af106a . This changes the char format
tests which were printing the pointer value of the C-string instead of its
contents, so this test failed on other machines. Now they just print the
bytes in a uint128_t.
Original commit description:
The previous tests apparently missed a few code branches in DumpDataExtractor
code. Also renames the 'test_instruction' which had the same name as another
test (and Python therefore ignored the test entirely).
This saves creating/destroying a builder every time we
perform some transform.
The tests show instruction ordering diffs resulting from
always inserting at the root instruction now, but those
should be benign.
This fixes various assertion failures that would otherwise be triggered
by a later patch to move SIWholeQuadMode later in the pass pipeline.
Differential Revision: https://reviews.llvm.org/D82190
We have a division by zero crash currently when
the sh_entzize of the dynamic symbol table is 0.
Differential revision: https://reviews.llvm.org/D82180
It is possible to trigger a crash when a dynamic symbol has a
broken (too large) st_name and the DT_STRSZ is also broken.
We have the following code in the `Elf_Sym_Impl<ELFT>::getName`:
```
template <class ELFT>
Expected<StringRef> Elf_Sym_Impl<ELFT>::getName(StringRef StrTab) const {
uint32_t Offset = this->st_name;
if (Offset >= StrTab.size())
return createStringError(object_error::parse_failed,
"st_name (0x%" PRIx32
") is past the end of the string table"
" of size 0x%zx",
Offset, StrTab.size());
...
```
The problem is that `StrTab` here is a `ELFDumper::DynamicStringTab` member
which is not validated properly on initialization. So it is possible to bypass the
`if` even when the `st_name` is huge.
This patch fixes the issue.
Differential revision: https://reviews.llvm.org/D82201
For little endian targets, if we only need the lowest element and none of the extended bits then we can just use the (bitcasted) source vector directly.
We already do this in SimplifyDemandedBits, this adds the SimplifyMultipleUseDemandedBits equivalent.
Example of Matmul implementation in linalg.generic operation contained few mistakes that can puzzle new startes when trying to run the example.
Differential Revision: https://reviews.llvm.org/D82289
Summary:
In ASTMatcher, when we have `has(...)` and `hasParent(...)` called with the same internal matcher on the same node, the memoization process will mix-up the two calls because the direction of the traversal is not part of the memoization key.
This patch adds this information.
Reviewers: klimek
Reviewed By: klimek
Subscribers: Godin, njames93, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80025
This reverts commit 29b2c1ca72.
The patch causes the DT verifier failure like:
DominatorTree is different than a freshly computed one!
Not sure the patch itself it wrong but revert to investigate the failure.
We can't consider variable safe if out-of-lifetime access is possible.
So if StackLifetime can't prove that the instruction always uses
the variable when it's still alive, we consider it unsafe.
Usually DominatorTree provides this info, but here we use
StackLifetime. The reason is that in the next patch StackLifetime
will be used for actual lifetime checks and we can avoid
forwarding the DominatorTree into this code.
Summary:
Handle `\l` separately because a string literal can be in code like "string\\literal" with the `\l` inside. Also on Windows macros __FILE__ produces specific delimiters `\` and a directory or file may starts with the letter `l`.
Fix:
Use regex for replacing all `\l` (like `,\l`, `}\l`, `[\l`) except `\\l`, because a literal as a rule contains multiple `\` before `\l`.
Differential Revision: https://reviews.llvm.org/D82092
Summary: CMake's `find_package` outputs to the console on success, which confuses the smart console mode of the `ninja` build system. Let's quiet the success message and manually warn instead.
Reviewers: tstellar, phosek, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82276
When writing a unit test on replacing standard epilogue sequences with `BR __mspabi_func_epilog_<N>`, by manually asm-clobbering `rN` - `r10` for N = 4..10, everything worked well except for seeming inability to clobber r4.
The problem was that MSP430 code generator of LLVM used an obsolete name FP for that register. Things were worse because when `llc` read an unknown register name, it silently ignored it.
Differential Revision: https://reviews.llvm.org/D82184
Nathan James