Revert "[clang] Implement ElaboratedType sugaring for types written bare"

This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because it
stills breaks the LLDB tests. This was re-landed wi

Revert "[clang] Implement ElaboratedType sugaring for types written bare"

This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because it
stills breaks the LLDB tests. This was re-landed without addressing the
issue or even agreement on how to address the issue. More details and
discussion in https://reviews.llvm.org/D112374.

show more ...

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which go

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.

3) This patch could exposed a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <[email protected]>

Differential Revision: https://reviews.llvm.org/D112374

show more ...

Revert "[clang] Implement ElaboratedType sugaring for types written bare"

This reverts commit bdc6974f92304f4ed542241b9b89ba58ba6b20aa because it
breaks all the LLDB tests that import the std module

Revert "[clang] Implement ElaboratedType sugaring for types written bare"

This reverts commit bdc6974f92304f4ed542241b9b89ba58ba6b20aa because it
breaks all the LLDB tests that import the std module.

import-std-module/array.TestArrayFromStdModule.py
import-std-module/deque-basic.TestDequeFromStdModule.py
import-std-module/deque-dbg-info-content.TestDbgInfoContentDequeFromStdModule.py
import-std-module/forward_list.TestForwardListFromStdModule.py
import-std-module/forward_list-dbg-info-content.TestDbgInfoContentForwardListFromStdModule.py
import-std-module/list.TestListFromStdModule.py
import-std-module/list-dbg-info-content.TestDbgInfoContentListFromStdModule.py
import-std-module/queue.TestQueueFromStdModule.py
import-std-module/stack.TestStackFromStdModule.py
import-std-module/vector.TestVectorFromStdModule.py
import-std-module/vector-bool.TestVectorBoolFromStdModule.py
import-std-module/vector-dbg-info-content.TestDbgInfoContentVectorFromStdModule.py
import-std-module/vector-of-vectors.TestVectorOfVectorsFromStdModule.py

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45301/

show more ...

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which go

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

Signed-off-by: Matheus Izvekov <[email protected]>

Differential Revision: https://reviews.llvm.org/D112374

show more ...

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note.

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.

For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.

It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.

Differential Revision: https://reviews.llvm.org/D120296

show more ...

Reland (2) "[AST] Add RParen loc for decltype AutoTypeloc.""

The patch was reverted because it caused a crash during PCH build -- we
missed to update the RParenLoc in TreeTransform<Derived>::Transfo

Reland (2) "[AST] Add RParen loc for decltype AutoTypeloc.""

The patch was reverted because it caused a crash during PCH build -- we
missed to update the RParenLoc in TreeTransform<Derived>::TransformAutoType.

This relands 55d96ac and 37ec65e with a test and fix.

show more ...

Revert (2) "[AST] Add RParen loc for decltype AutoTypeloc."

This reverts commit 41fbdfa4d5601cccbcdc0ded8ef35190d502f7f3.

The commit breaks stage 2 builds with debug info, e.g.
https://green.lab.ll

Revert (2) "[AST] Add RParen loc for decltype AutoTypeloc."

This reverts commit 41fbdfa4d5601cccbcdc0ded8ef35190d502f7f3.

The commit breaks stage 2 builds with debug info, e.g.
https://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/5088/console

Clang crashes with the following assertion when building
llvm-project/llvm/lib/Support/Timer.cpp

/usr/local/bin/sccache /Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/host-compiler/bin/clang++ -DGTEST_HAS_RTTI=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/lib/Support -Iinclude -I/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/include -fno-stack-protector -fno-common -Wno-profile-instr-unprofiled -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -fmodules -fmodules-cache-path=/Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/clang-build/Build/module.cache -fcxx-modules -Xclang -fmodules-local-submodule-visibility -gmodules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -flto=thin -O2 -g -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -std=c++14 -fno-exceptions -fno-rtti -MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o -MF lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o.d -o lib/Support/CMakeFiles/LLVMSupport.dir/Timer.cpp.o -c /Users/buildslave/jenkins/workspace/clang-stage2-Rthinlto/llvm-project/llvm/lib/Support/Timer.cpp
Assertion failed: (((getOffset()+Offset) & MacroIDBit) == 0 && "offset overflow"), function getLocWithOffset, file /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/clang/include/clang/Basic/SourceLocation.h, line 135.

show more ...

Reland "[AST] Add RParen loc for decltype AutoTypeloc."

Reland 55d96ac and 37ec65e with a clang-tidy fix.

Revert "[AST] Add RParen loc for decltype AutoTypeloc."

This breaks a clang-tidy check, needs to investigate and fix. Revert
them to bring the buildbot back.

This reverts commit 55d96ac3dc56bdebea8

Revert "[AST] Add RParen loc for decltype AutoTypeloc."

This breaks a clang-tidy check, needs to investigate and fix. Revert
them to bring the buildbot back.

This reverts commit 55d96ac3dc56bdebea854952a724c2a50d96ce19 and
37ec65e1d705f56fe5551de1dfcbac1e071588a2

show more ...

[AST] Add RParen loc for decltype AutoTypeloc.

Differential Revision: https://reviews.llvm.org/D116919

Properly determine the end location of an ObjCObjectPointerType.

After rGa9db0a804a53, we correctly determined the end for pointer types
like `id` that are spelled without a `*`, but incorrectly det

Properly determine the end location of an ObjCObjectPointerType.

After rGa9db0a804a53, we correctly determined the end for pointer types
like `id` that are spelled without a `*`, but incorrectly determined the
end for pointer types spelled with a `*`.

show more ...

[AST] Fix the EndLoc calculation for ObjCObjectPointer

There is an issue where the AST code does not compute the correct SourceRange
for a ObjCObjectPointer.

From Richard Smith (ie @zygoloid) in di

[AST] Fix the EndLoc calculation for ObjCObjectPointer

There is an issue where the AST code does not compute the correct SourceRange
for a ObjCObjectPointer.

From Richard Smith (ie @zygoloid) in discord:

I think the problem is that we set an invalid location for the * (because there
isn't one): https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaType.cpp#L1121
And then we use the default getLocalSourceRangeImpl for a PointerLikeTypeLoc
that just assumes the * location is the type's end location:
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/TypeLoc.h#L1293
Possibly we should be special-casing that here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/TypeLoc.cpp#L228

My change:

introduces a AST dump test to show the issue in the first commit
special cases ObjCObjectPointerType in the second commit to correctly compute
the end location

show more ...

[Clang] Add __ibm128 type to represent ppc_fp128

Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC
target generates ppc_fp128 type from long double now, but there's option
(-mab

[Clang] Add __ibm128 type to represent ppc_fp128

Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC
target generates ppc_fp128 type from long double now, but there's option
(-mabi=(ieee|ibm)longdouble) to control it and we're going to do
transition from IBM extended double-double ppc_fp128 to IEEE fp128 in
the future.

This patch adds type __ibm128 which always represents ppc_fp128 in IR,
as what GCC did for that type. Without this type in Clang, compilation
will fail if compiling against future version of libstdcxx (which uses
__ibm128 in headers).

Although all operations in backend for __ibm128 is done by software,
only PowerPC enables support for it.

There's something not implemented in this commit, which can be done in
future ones:

- Literal suffix for __ibm128 type. w/W is suitable as GCC documented.
- __attribute__((mode(IF))) should be for __ibm128.
- Complex __ibm128 type.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D93377

show more ...

[Clang][RISCV] Define RISC-V V builtin types

Add the types for the RISC-V V extension builtins.

These types will be used by the RISC-V V intrinsics which require
types of the form <vscale x 1 x i64

[Clang][RISCV] Define RISC-V V builtin types

Add the types for the RISC-V V extension builtins.

These types will be used by the RISC-V V intrinsics which require
types of the form <vscale x 1 x i64>(LMUL=1 element size=64) or
<vscale x 4 x i32>(LMUL=2 element size=32), etc. The vector_size
attribute does not work for us as it doesn't create a scalable
vector type. We want these types to be opaque and have no operators
defined for them. We want them to be sizeless. This makes them
similar to the ARM SVE builtin types. But we will have quite a bit
more types. This patch adds around 60. Later patches will add
another 230 or so types representing tuples of these types similar
to the x2/x3/x4 types in ARM SVE. But with extra complexity that
these types are combined with the LMUL concept that is unique to
RISCV.

For more background see this RFC
http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html

Authored-by: Roger Ferrer Ibanez <[email protected]>
Co-Authored-by: Hsiangkai Wang <[email protected]>

Differential Revision: https://reviews.llvm.org/D92715

show more ...

Revert "Following up on PR48517, fix handling of template arguments that refer"

Combined with 'da98651 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d3) caused verifier
error

Revert "Following up on PR48517, fix handling of template arguments that refer"

Combined with 'da98651 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d3) caused verifier
errors when building Chromium. See https://crbug.com/1168494#c1 for a
reproducer.

Additionally it reverts changes that were dependent on this one, see
below.

> Following up on PR48517, fix handling of template arguments that refer
> to dependent declarations.
>
> Treat an id-expression that names a local variable in a templated
> function as being instantiation-dependent.
>
> This addresses a language defect whereby a reference to a dependent
> declaration can be formed without any construct being value-dependent.
> Fixing that through value-dependence turns out to be problematic, so
> instead this patch takes the approach (proposed on the core reflector)
> of allowing the use of pointers or references to (but not values of)
> dependent declarations inside value-dependent expressions, and instead
> treating template arguments as dependent if they evaluate to a constant
> involving such dependent declarations.
>
> This ends up affecting a bunch of OpenMP tests, due to OpenMP
> imprecisely handling instantiation-dependent constructs, bailing out
> early instead of processing dependent constructs to the extent possible
> when handling the template.
>
> Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and
> reverted because a dependency commit was reverted.

This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e.

It also restores clang/test/SemaCXX/coroutines.cpp to its state before
da986511fb9da1a46a0ca4dba2e49e2426036303.

Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."

> Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
> reverted because a dependency commit was reverted. This incorporates the
> following follow-on commits that were also reverted:
>
> 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim
> ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me
> 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall
> 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki

This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786.

Revert "[msabi] Mangle a template argument referring to array-to-pointer decay"

> [msabi] Mangle a template argument referring to array-to-pointer decay
> applied to an array the same as the array itself.
>
> This follows MS ABI, and corrects a regression from the implementation
> of generalized non-type template parameters, where we "forgot" how to
> mangle this case.

This reverts commit 18e093faf726d15f210ab4917142beec51848258.

show more ...

[c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
reverted because a dependency commit was re

[c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
reverted because a dependency commit was reverted. This incorporates the
following follow-on commits that were also reverted:

7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim
ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me
95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall
430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki

show more ...

Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."

This reverts commit 9e08e51a20d0d2b1c5724bb17e969d036fced4cd.

This is part of 5 commits being reverted

Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."

This reverts commit 9e08e51a20d0d2b1c5724bb17e969d036fced4cd.

This is part of 5 commits being reverted due to https://crbug.com/1161059. See bug for repro.

show more ...

[c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

[PowerPC] Enable paired vector type and intrinsics when MMA is disabled

This patch enables the Clang type __vector_pair and its associated LLVM
intrinsics even when MMA is disabled. With this patch,

[PowerPC] Enable paired vector type and intrinsics when MMA is disabled

This patch enables the Clang type __vector_pair and its associated LLVM
intrinsics even when MMA is disabled. With this patch, the type is now controlled
by the PPC paired-vector-memops option. The builtins and intrinsics will be
renamed to drop the mma prefix in another patch.

Differential Revision: https://reviews.llvm.org/D91819

show more ...

[Clang][PowerPC] Add __vector_pair and __vector_quad types

Define the __vector_pair and __vector_quad types that are used to manipulate
the new accumulator registers introduced by MMA on PowerPC. Be

[Clang][PowerPC] Add __vector_pair and __vector_quad types

Define the __vector_pair and __vector_quad types that are used to manipulate
the new accumulator registers introduced by MMA on PowerPC. Because these two
types are specific to PowerPC, they are defined in a separate new file so it
will be easier to add other PowerPC specific types if we need to in the future.

Differential Revision: https://reviews.llvm.org/D81508

show more ...

[AST] Reduce the size of TemplateArgumentLocInfo.

allocate the underlying data of Template kind separately, this would reduce AST
memory usage

- TemplateArgumentLocInfo 24 => 8 bytes
- TemplateArgu

[AST] Reduce the size of TemplateArgumentLocInfo.

allocate the underlying data of Template kind separately, this would reduce AST
memory usage

- TemplateArgumentLocInfo 24 => 8 bytes
- TemplateArgumentLoc 48 => 32 bytes
- DynTypeNode 56 => 40 bytes

ASTContext::.getASTAllocatedMemory changes:
SemaDecl.cpp 255.5 MB => 247.5MB
SemaExpr.cpp 293.5 MB => 283.5MB

Differential Revision: https://reviews.llvm.org/D87080

show more ...

[ARM] Add __bf16 as new Bfloat16 C Type

Summary:
This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with

[ARM] Add __bf16 as new Bfloat16 C Type

Summary:
This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with the Bfloat16 extension of the Armv8.6-a architecture, as
detailed here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

The bfloat type, and its properties are specified in the Arm Architecture
Reference Manual:

https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile

In detail this patch:
- introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type.

This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.

The following people contributed to this patch:
- Luke Cheeseman
- Momchil Velikov
- Alexandros Lamprineas
- Luke Geeson
- Simon Tatham
- Ties Stuij

Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli

Reviewed By: SjoerdMeijer

Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76077

show more ...

[Matrix] Implement matrix index expressions ([][]).

This patch implements matrix index expressions
(matrix[RowIdx][ColumnIdx]).

It does so by introducing a new MatrixSubscriptExpr(Base, RowIdx, Col

[Matrix] Implement matrix index expressions ([][]).

This patch implements matrix index expressions
(matrix[RowIdx][ColumnIdx]).

It does so by introducing a new MatrixSubscriptExpr(Base, RowIdx, ColumnIdx).
MatrixSubscriptExprs are built in 2 steps in ActOnMatrixSubscriptExpr. First,
if the base of a subscript is of matrix type, we create a incomplete
MatrixSubscriptExpr(base, idx, nullptr). Second, if the base is an incomplete
MatrixSubscriptExpr, we create a complete
MatrixSubscriptExpr(base->getBase(), base->getRowIdx(), idx)

Similar to vector elements, it is not possible to take the address of
a MatrixSubscriptExpr.
For CodeGen, a new MatrixElt type is added to LValue, which is very
similar to VectorElt. The only difference is that we may need to cast
the type of the base from an array to a vector type when accessing it.

Reviewers: rjmccall, anemet, Bigcheese, rsmith, martong

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D76791

show more ...

[OPENMP50]Add initial support for OpenMP 5.0 iterator.

Added basic parsing/semantic analysis/(de)serialization support for
iterator expression introduced in OpenMP 5.0.

Revert "[OPENMP50]Add initial support for OpenMP 5.0 iterator."

This reverts commit f08df464ae89972a777c0a7e299a2c153a9829d8 to fix the
bug with serialization support for iterator expression.