The checkBuiltinArgument helper takes an integer ArgIndex and is
documented as performing normal type-checking on that argument. However,
it mistakenly hardcodes the argument index to zero when retrieving the
argument from the call expression.
This hadn't been noticed previously as all in-tree uses typecheck the
0th argument anyway.
Add supports in FindTarget and IncludeCleaner. This would
improve AST-based features on a tempalte which is found via a using
declaration. For example, go-to-def on `vect^or<int> v;` gives us the
location of `using std::vector`, which was not previously.
Base on https://reviews.llvm.org/D123127
Differential Revision: https://reviews.llvm.org/D123212
D119136 changed how captures are handled in a lambda call operator
declaration, but did not properly handled dependant context,
which led to crash when refering to init-captures in
a trailing return type.
We fix that bug by making transformations more symetric with parsing,
ie. we first create the call operator, then transform the capture,
then compute the type of the lambda call operaror.
This ensures captures exist and have the right type when
we parse a trailing requires-clause / return type.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124012
Like D118875, but for ubsan, asan, etc.
With this, I can successfully run:
bin/clang++ -target x86_64-apple-ios14.0-macabi foo.cc \
-isysroot $(xcrun -show-sdk-path) -fsanitize=undefined
with a locally built libclang_rt.ubsan_osx_dynamic.dylib.
Differential Revision: https://reviews.llvm.org/D124059
Add a helper used to implement the build methods generated by ods-gen. The change reduces code size and compilation time since all structured op builders use the same build method. The change reduces the LinalgOps.cpp compilation time from 10.2s to 9.8s (debug build).
Depends On D123987
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D124003
We add a new clang library called `clangSupport` for putting those utils which can be used in clang table-gen and other clang component.
We tried to put that into `llvm/Support`, but actually those stuffs only used in clang* and clang-tblgen, so I think that might be better to create `clang/Support`
* clang will used that in https://reviews.llvm.org/D111617.
Reviewed By: khchen, MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D121984
The revision avoids template methods for parsing and printing that are replicated for every named operation. Instead, the new methods take a regionBuilder argument. The revision reduces the compile time of LinalgOps.cpp from 11.2 to 10.2 seconds (debug build).
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D123987
We can process the long shuffles (working across several actual
vector registers) in the best way if we take the actual register
represantion into account. We can build more correct representation of
register shuffles, improve number of recognised buildvector sequences.
Also, same function can be used to improve the cost model for the
shuffles. in future patches.
Part of D100486
Differential Revision: https://reviews.llvm.org/D115653
NFC. Drop trailing end of line white space in GPU async ops' printer
whenever the list of async deps is empty.
Reviewed By: mehdi_amini, rriddle
Differential Revision: https://reviews.llvm.org/D123754
Add RegionBranchOpInterface on affine.for op so that transforms relying
on RegionBranchOpInterface can support affine.for. E.g.:
buffer-deallocation pass.
Reviewed By: herhut
Differential Revision: https://reviews.llvm.org/D123568
Summary:
Some platforms like Mach-O require different handling of section names.
This is not supported on Mac-OS or Windows yet so we shouldn't be
testing the compilation there. Add an explicit triple to the tests.
Note that GlobalISel does not actually use the SVS addressing mode
for these cases yet because it chooses the VGPR bank for
G_FRAME_INDEX; see the TODO comment in
AMDGPURegisterBankInfo::getInstrMapping.
Rather than checking the bitcast pointer element types, compare
the element type of the access and the GEP result type.
The entire code is dubious due to the inspection of GEP structure,
but this at least preserves the spirit of the existing code.
Writes into tensors that are definied outside of a repetitive region, but with the write happening inside of the repetitive region were previously not considered conflicts. This was incorrect.
E.g.:
```
%0 = ... : tensor<?xf32>
scf.for ... {
"reading_op"(%0) : tensor<?xf32>
%1 = "writing_op"(%0) : tensor<?xf32> -> tensor<?xf32>
...
}
```
In the above example, "writing_op" should be out-of-place.
This commit fixes the bufferization for any op that declares its repetitive semantics via RegionBranchOpInterface.
Re-run the update_cc_test_checks.py to update expected result.
I'm not sure why those tests are passed before.
Differential Revision: https://reviews.llvm.org/D124062
The routine that facilitated symbols to be explicitly allowed asked
the name of the called function, which resulted in a crash when the
check was accidentally run on non-trivial C++ code.
Differential Revision: http://reviews.llvm.org/D123992
Reviewed By: aaron.ballman
A missing "!" in the call interface lowering caused all derived type
arguments without length parameters that require and explicit interface
to be passed via fir.box (runtime descriptor).
This was not the intent: there is no point passing a simple derived type
scalars or explicit shapes by descriptor just because they have an attribute
like TARGET. This would actually be problematic with existing code that is
not always 100% compliant: some code implicitly calls procedures with
TARGET dummy attributes (this is not something a compiler can enforce
if the call and procedure definition are not in the same file).
Add a Scope::IsDerivedTypeWithLengthParameter to avoid passing derived
types with only kind parameters by descriptor. There is no point, the
callee knows about the kind parameter values.
Differential Revision: https://reviews.llvm.org/D123990
Fixes [[ https://github.com/llvm/llvm-project/issues/38995 | #38995 ]]
This is an attempt to modify the regular expression to identify
`@import` and `import` alongside the regular `#include`. The challenging
part was not to support `@` in addition to `#` but how to handle
everything that comes after the `include|import` keywords. Previously
everything that wasn't `"` or `<` was consumed. But as you can see in
this example from the issue #38995, there is no `"` or `<` following the
keyword:
```
@import Foundation;
```
I experimented with a lot of fancy and useful expressions in [this
online regex tool](https://regex101.com) only to find out that some
things are simply not supported by the regex implementation in LLVM.
* For example the beginning `[\t\ ]*` should be replacable by the
horizontal whitespace character `\h*` but this will break the
`SortIncludesTest.LeadingWhitespace` test.
That's why I've chosen to come back to the basic building blocks.
The essential change in this patch is the change from this regular
expression:
```
^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">])
~ ~~~~~~~~~~~~~~
^ ^
| |
only support # prefix not @ |
only support "" and <> as
delimiters
no support for C++ modules and ;
ending. Also this allows for ">
or <" or "" or <> which all seems
either off or wrong.
```
to this:
```
^[\t\ ]*[@#][\t\ ]*(import|include)([^"]*("[^"]+")|[^<]*(<[^>]+>)|[\t\
]*([^;]+;))
~~~~ ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
^ ^ ^ ^ ^
| | | | |
Now support @ and #. Clearly support "" and <> as
well as an
include name without enclosing
characters.
Allows for no mixture of "> or
<" or
empty include names.
```
Here is how I've tested this patch:
```
ninja clang-Format
ninja FormatTests
./tools/clang/unittests/Format/FormatTests
--gtest_filter=SortIncludesTest*
```
And if that worked I doubled checked that nothing else broke by running
all format checks:
```
./tools/clang/unittests/Format/FormatTests
```
One side effect of this change is it should partially support
[C++20 Module](https://en.cppreference.com/w/cpp/language/modules)
`import` lines without the optional `export` in front. Adding
this can be a change on its own that shouldn't be too hard. I say
partially because the `@` or `#` are currently *NOT* optional in the
regular expression.
I see an opportunity to optimized the matching to exclude `@include` for
example. But eventually these should be caught by the compiler, so...
With my change, the matching group is not at a fixed position any
longer. I decided to
choose the last match (group) that is not empty.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D121370
