Bionic's sys/user.h declares a "struct user". The header tends to be
included, and when it is, it conflicts with "namespace user". Rename
user to User.
Differential Revision: https://reviews.llvm.org/D139380
This covers `SDot`, `SUDot`, and `UDot`. The `*AccSat` version will be
added in a follow-up revision.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139242
Since changes to account for LMUL in scheduler model existed over patches, we had to keep
both LMUL specific and all LMUL classes around. Now that only the LMUL specific
classes are used, we can remove the old ones.
It is likley that subtargets act differently for a vector load store instructions based on the LMUL.
This patch creates seperate SchedRead, SchedWrite, WriteRes, ReadAdvance for each relevant LMUL.
Differential Revision: https://reviews.llvm.org/D137429
It is likley that subtargets act differently for vector fixed-point arithmetic instructions
based on the LMUL. This patch creates seperate SchedRead, SchedWrite, WriteRes, ReadAdvance
for each relevant LMUL.
Differential Revision: https://reviews.llvm.org/D137428
Update the sort order to make sure that comesBefore is never used from
conditional facts, which are instructions but may use DFS numbers from
different blocks.
This fixes a crash in the added test on some platforms.
We need a scratch GPR to increment the base pointer for each subsequent
register. We currently reuse the input GPR for the base pointer without
declaring it as a Def of the pseudo.
We can't add it as a Def of the pseudo at creation time because it doesn't
get register allocated. This was tried in D109405.
Seems the only choice we have is to scavenge the GPR. This patch
moves the expansion to eliminateFrameIndex where we can create
virtual registers that will be scavenged. This also eliminates the
extra operand for passing vlenb from frame lowering to expand pseudos.
I need to do more testing on real world code, but wanted to get this
up for early review.
I hope this will fix the issue reported in D123394, but I haven't
checked yet.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D139169
Make the types consistent with each other, and return size_t instead of a long int.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D126121
It introduces a pattern that swaps `linalg.generic + tensor.pack` to
`tensor.pack + linalg.generic`. It requires all the iteration types
being parallel; the indexing map of output operand is identiy. They can
all be relaxed in the future.
The user can decide whether the propagation should be applied or not by
passing a control function.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D138882
Some buildbots are failing in Clang and LLDB tests. (I guess the LLDB
failure is due to the explicit C language tests in DwarfUnit.cpp that
need to be updated - not sure what the Clang failures are about, they
seem to be still emitting C99 when we're expecting C11 and I checked
those tests pass... maybe systems with a different C language version
default?)
This reverts commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0.
This patch uses refactors CMake files related to `PluginInterface` in `plugins-nextgen` to handle LLVM dependences in a better way.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D139371
This assertion failure was introduced in 9ed2e68c9ae5 and is
manifested when both RemoveBracesLLVM and MacroBlockBegin are set.
Fixes#59335.
Differential Revision: https://reviews.llvm.org/D139281
The 3-parameter std::equal used in this code access FileBuffer from [0,
OutputBuffer->getBufferEnd() - OutputBuffer->getBufferStart()). If the
size of FileBuffer is shorter than OutputBuffer, this ends up
overflowing.
This wasn't found on the sanitizer buildbots as they use an instrumented
libcxx, and libcxx implements std::equal using a loop. libstdc++ on my
local macine finds the bug, as it implements std::equal using bcmp(),
which ASan intercepts and does a range check.
The existing test doesn't technically do a buffer-overflow, but the code
definitely can. If OutputBuffer was "AAABBB" and FileBuffer was "AAA",
then the code would overflow.
Reviewed By: abrachet
Differential Revision: https://reviews.llvm.org/D139457
This reverts commit e2c868fbf7c304ed1814ed53fdeb7605042f3c8c.
The buildbot failure from the earlier land has been fixed by 7c7e39db7a.
Differential Revision: https://reviews.llvm.org/D137370
This reverts commit ac3096e1dd77a2687797d38976d5f8c93f7353e5.
The buildbot failure from the earlier patch set has been fixed by 7c7e39db7a.
Differential Revision: https://reviews.llvm.org/D137369
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
Differential Revision: https://reviews.llvm.org/D138597
The [initial implementation][1] of __attribute__((format)) on non-variadic functions
accidentally only accepted one data argument. This worked:
```c
__attribute__((format(printf, 1, 2)))
void f(const char *, int);
```
but this didn't:
```c
__attribute__((format(printf, 1, 2)))
void f(const char *, int, int);
```
This is due to an oversight in changing the way diagnostics are emitted for
`attribute((format))`, and to a coincidence in the handling of the variadic case. Test
cases only covered the case that worked by coincidence.
Before the previous change, using `__attribute__((format))` on a non-variadic function at
all was an error and clang bailed out. After that change, it only generates a GCC
compatibility warning. However, as execution falls through, it hits a second diagnostic
when the first data argument is neither 0 nor the last parameter of the function.
This change updates that check to allow any parameter after the format string to be the
first data argument when the function is non-variadic. When the function is variadic, it
still needs to be the index of the `...` "parameter". Attribute documentation is updated
to reflect the change and new tests are added to verify that it works with _two_ data
parameters.
[1]: https://reviews.llvm.org/D112579
Radar-Id: rdar://102069446
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D137603
Support fir.class in genScalarUserDefinedAssignmentCall so
emboxing is done correctly.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139435
This patch adds the following NFC fixes to PPCInstrInfo.cpp when getting the DefMI:
- Fix documentation error to state that we want to flag a use of register
between the def and the MI (in post-RA)
- Setting the DefMI to null if the DefMI is neither an LI or and ADDI
(while still being in SSA form).
In terms of setting the DefMI to null, this change aims to account for the
scenario of when we end up going through all operands on the machine instruction
MI and updating OpNoForForwarding accordingly once an ADDI is found as the DefMI.
It is possible that once an ADDI is found, we will continue to go through all
operands in attempts to find an LI, but end up looking at every operand until
we reach the end if we have not yet found an LI. In the case where the end is
reached and we never end up finding an LI/ADDI, DefMI would be pointing to the
last operand of MI while OpNoForForwarding would still be pointing at the
previous ADDI operand found. We reset DefMI to avoid having DefMI point to an
instruction that differs from the one represented by OpNoForForwarding.
Differential Revision: https://reviews.llvm.org/D137483
In the Ch6 of the Toy Example for MLIR, there is a broken link. If ones goes to [the page for Chapter 6](https://mlir.llvm.org/docs/Tutorials/Toy/Ch-6/), and click on the link "Conversion to the LLVM IR Dialect", one will see it takes you to a page that no longer exists.
I believe this should actually be [this link](https://mlir.llvm.org/docs/TargetLLVMIR/).
Note to reviewers that this is my first submitted patch to LLVM, and using the phabricator system, so there is a higher risk that I have made an error, and brief feedback on these patch notes would be appreciated.
Reviewer rational: Users who git blame say contributed to the tutorial.
I believe that automated tests on these markdown docs could reduce the risk of this kind of error occurring again. For example, [this Python package](https://pypi.org/project/linkcheckmd/) checks for broken markdown links. However, I am unsure where in the existing testing infrastructure this could go, I am only somewhat familiar with the C++ side.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D133977
This revision adapts the pattern in LinAlg to work on DPS interface, and
adds it to canonicalization patterns of tensor dialect. The
InsertSliceOp is skipped in the pattern because it has its own logic
about folding tensor.cast ops.
Reviewed By: pifon2a
Differential Revision: https://reviews.llvm.org/D139375
Currently, assemblyFormat `custom<A>($a) custom<B>($b)` has different spacing
if used for Ops vs Attrs/Types. Ops insert a space if needed before the custom directive,
while attributes and types do not.
This leads to the following two patterns in attributes / types:
```
# 1. Whitespace literal
let assemblyFormat = "... ` ` custom<A>($a)"
# 2. Custom printer code includes spacing
void printB(...) {
printer << ' ' << b;
}
```
Moving this spacing into the generated code allows for some cleanup in mlir and
improves the consistency of custom directives.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D138235
When a new function "NewF" is created with instructions extracted from
another function "OldF", the CodeExtractor only preserves debug
line/column of the extracted instructions. However:
1. Any inlinedAt nodes are dropped.
2. The scope chain is replaced with a single node, the Subprogram of NewF.
Both of these are incorrect: most of the debug metadata from the
original instructions should be preserved. We only need to update the
Subprogram found at the scope of the last node of the inline chain; this
Subprogram used to be OldF but now should be NewF.
Differential Revision: https://reviews.llvm.org/D139217
The repeated instructions make the file long and difficult to read.
Simplify them with .irp directives.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D139368
On SystemZ, the vector ABI changes depending on the presence of hardware
vector support. Therefore, each binary compiled with a visible vector ABI
(e.g. one that calls an external function with a vector argument) should be
marked with a .gnu_attribute describing this.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D105067
And make use of this from clangd's CodeComplete and IncludeFixer, although currently they are both restricted only to #include symbols.
Differential Revision: https://reviews.llvm.org/D128677
The IncludeDirective contains both Include (the current behavior) and Import,
which we can use in the future to provide #import suggestions for
Objective-C files/symbols.
Differential Revision: https://reviews.llvm.org/D128457
