Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort.
Refer the comments section in D44363 for a list of all the required patches.
Reviewers: stoklund, kparzysz, dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45144
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329451 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Recursive lookups are handled by the Resolver, so the loop was purely
a waste of runtime.
Change-Id: I2bd23a68b478aea0bbac1a86ca7635adffa28688
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44624
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328118 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instantiating def's and defm's needs to perform the following steps:
- for defm's, clone multiclass def prototypes and subsitute template args
- for def's and defm's, add subclass definitions, substituting template
args
- clone the record based on foreach loops and substitute loop iteration
variables
- override record variables based on the global 'let' stack
- resolve the record name (this should be simple, but unfortunately it's
not due to existing .td files relying on rather silly implementation
details)
- for def(m)s in multiclasses, add the unresolved record as a multiclass
prototype
- for top-level def(m)s, resolve all internal variable references and add
them to the record keeper and any active defsets
This change streamlines how we go through these steps, by having both
def's and defm's feed into a single addDef() method that handles foreach,
final resolve, and routing the record to the right place.
This happens to make foreach inside of multiclasses work, as the new
test case demonstrates. Previously, foreach inside multiclasses was not
forbidden by the parser, but it was de facto broken.
Another side effect is that the order of "instantiated from" notes in error
messages is reversed, as the modified test case shows. This is arguably
clearer, since the initial error message ends up pointing directly to
whatever triggered the error, and subsequent notes will point to increasingly
outer layers of multiclasses. This is consistent with how C++ compilers
report nested #includes and nested template instantiations.
Change-Id: Ica146d0db2bc133dd7ed88054371becf24320447
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44478
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328117 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Otherwise, patterns like in the test case produce cryptic error
messages about fields being resolved incompletely.
Change-Id: I713c0191f00fe140ad698675803ab1f8823dc5bd
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44476
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327850 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The docs already claim that this happens, but so far it hasn't. As a
consequence, existing TableGen files get this wrong a lot, but luckily
the fixes are all reasonably straightforward.
To make this work with all the existing forms of self-references (since
the true type of a record is only built up over time), the lookup of
self-references in !cast is delayed until the final resolving step.
Change-Id: If5923a72a252ba2fbc81a889d59775df0ef31164
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D44475
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327849 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These are cases of self-references that exist today in practice. Let's
add tests for them to avoid regressions.
The self-references in PPCInstrInfo.td can be expressed in a simpler
way. Allowing this type of self-reference while at the same time
consistently doing late-resolve even for self-references is problematic
because there are references to fields that aren't in any class. Since
there's no need for this type of self-reference anyway, let's just
remove it.
Change-Id: I914e0b3e1ae7adae33855fac409b536879bc3f62
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: nemanjai, wdng, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D44474
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327848 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Make sure that we always fold immediately, so there's no point in
attempting to re-fold when nothing changes.
Change-Id: I069e1989455b6f2ca8606152f6adc1a5e817f1c8
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44198
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327847 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Cast-from-string for records isn't going away, but cast-from-string for
variables is a pretty dodgy feature to have, especially when referencing
template arguments. It's doubtful that this ever worked in a reliable
way, and nobody seems to be using it, so let's get rid of it and get
some related cleanups.
Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44195
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327844 91177308-0d34-0410-b5e6-96231b3b80d8
Additionally, allow more than two operands to !con, !add, !and, !or
in the same way as is already allowed for !listconcat and !strconcat.
Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93
Differential revision: https://reviews.llvm.org/D44112
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327494 91177308-0d34-0410-b5e6-96231b3b80d8
This allows constructing DAG nodes with programmatically determined
names, and can simplify constructing DAG nodes in other cases as
well.
Also, add documentation and some very simple tests for the already
existing !con.
Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7
Differential revision: https://reviews.llvm.org/D44110
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327492 91177308-0d34-0410-b5e6-96231b3b80d8
Allows capturing a list of concrete instantiated defs.
This can be combined with foreach to create parallel sets of def
instantiations with less repetition in the source. This purpose is
largely also served by multiclasses, but in some cases multiclasses
can't be used.
The motivating example for this change is having a large set of
intrinsics, which are generated from the IntrinsicsBackend.td file
included by Intrinsics.td, and a corresponding set of instruction
selection patterns, which are generated via the backend's .td files.
Multiclasses cannot be used to eliminate the redundancy in this case,
because a multiclass cannot span both LLVM's common .td files and
the backend .td files at the same time.
Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b
Differential revision: https://reviews.llvm.org/D44109
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327121 91177308-0d34-0410-b5e6-96231b3b80d8
The changes to FieldInit are required to make field references (Def.field)
work inside a ForeachDeclaration: previously, Def.field wasn't resolved
immediately when Def was already a fully resolved DefInit.
Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327120 91177308-0d34-0410-b5e6-96231b3b80d8
Use the default ParseValueMode instead of ParseForeachMode when
parsing the rule
ForeachDeclaration ::= ID '=' '[' ValueList ']'
because the only difference between the two is how an open brace '{'
is handled at the end. In the context of foreach, the 'in' keyword
will appear after the ForeachDeclaration, so this special handling
of '{' is not required.
Change-Id: I4d86bb73bab9ec26752e1273e5213df77cf28d1d
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327119 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Only instantiate anonymous records once all variable references in template
arguments have been resolved. This allows patterns like the new test case,
which in practice can appear in expressions like:
class IntrinsicTypeProfile<list<LLVMType> ty, int shift> {
list<LLVMType> types =
!listconcat(ty, [llvm_any_ty, LLVMMatchType<shift>]);
}
class FooIntrinsic<IntrinsicTypeProfile P, ...>
: Intrinsic<..., P.types, ...>;
Without this change, the anonymous LLVMMatchType instantiation would
never get resolved.
Another consequence of this change is that anonymous inline
instantiations are uniqued via the folding set of the newly introduced
VarDefInit.
Change-Id: I7a7041a20e297cf98c9109b28d85e64e176c932a
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326788 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
So that we will be able to generate new anonymous names more easily
outside the parser as well.
Change-Id: I28f396a7bdbc3ff0c665d466abbd3d31376e21b4
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43755
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326787 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are various places where resolving and constant folds can
get stuck, especially around casts. We don't always signal an
error for those, because in many cases they can legitimately
occur without being an error in the "untaken branch" of an !if.
Change-Id: I3befc0e4234c8e6cc61190504702918c9f29ce5c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43754
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326786 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Distinguish two relationships between types: is-a and convertible-to.
For example, a bit is not an int or vice versa, but they can be
converted into each other (with range checks that you can think of
as "dynamic": unlike other type checks, those range checks do not
happen during parsing, but only once the final values have been
established).
Actually converting initializers between types is subtle: even
when values of type A can be converted to type B (e.g. int into
string), it may not be possible to do so with a concrete initializer
(e.g., a VarInit that refers to a variable of type int cannot
be immediately converted to a string).
For this reason, distinguish between getCastTo and convertInitializerTo:
the latter implements the actual conversion when appropriate, while
the former will first try to do the actual conversion and fall back
to introducing a !cast operation so that the conversion will be
delayed until variable references have been resolved.
To make the approach of adding !cast operations to work, !cast needs
to fallback to convertInitializerTo when the special string <-> record
logic does not apply.
This enables casting records to a subclass, although that new
functionality is only truly useful together with !isa, which will be
added in a later change.
The test is removed because it uses !srl on a bit sequence,
which cannot really be supported consistently, but luckily
isn't used anywhere either.
Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43753
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326785 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
No functional change intended. The removed code has a loop for
recursive resolving, which is superseded by the recursive
resolving done by the Resolver implementations.
Add a test case which was broken by an earlier version of this
change.
Change-Id: Ib208d037b77a8bbb725977f1388601fc984723d8
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43655
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326784 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Allow RecordRecTy to represent the type "subclass of N superclasses",
where N may be zero. Furthermore, generate RecordRecTy instances only
with actual classes in the list.
Keeping track of multiple superclasses is required to resolve the type
of a list correctly in some cases. The old code relied on the incorrect
behavior of typeIsConvertibleTo, and an earlier version of this change
relied on a modified ordering of superclasses (it was committed in
r325884 and then reverted because unfortunately some of clang-tblgen's
backends depend on the ordering).
Previously, the DefInit for each Record would have a RecordRecTy of
that Record as its type. Now, all defs with the same superclasses will
share the same type.
This allows us to be more consistent about type checks involving records:
- typeIsConvertibleTo actually requires the LHS to be a subtype of the
RHS
- resolveTypes will return the least supertype of given record types in
all cases
- different record types in the two branches of an !if are handled
correctly
Add a test that used to be accepted without flagging the obvious type
error.
Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43680
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326783 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use the new resolver interface more explicitly, and avoid traversing
all the initializers multiple times.
Change-Id: I679e86988b309d19f25e6cca8b0b14ea150198a6
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43654
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326708 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use the new resolver interface more explicitly, and avoid traversing
all the initializers multiple times.
Change-Id: Ia4dcc6d42dd8b65e6079d318c6a202f36f320fee
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43653
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326707 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use the new resolver interface more explicitly, and avoid traversing
all the initializers multiple times.
Add a test case for a pattern that was broken by an earlier version
of this change.
An additional change is that we now remove *all* template arguments
after resolving them.
Change-Id: I86c828c8cc84c18b052dfe0f64c0d5cbf3c4e13c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43652
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326706 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This changes the syntax of !foreach so that the first "parameter" is
a new syntactic variable: !foreach(x, lst, expr) will define the
variable x within the scope of expr, and evaluation of the !foreach
will substitute elements of the given list (or dag) for x in expr.
Aside from leading to a nicer syntax, this allows more complex
expressions where x is deeply nested, or even constant expressions
in which x does not occur at all.
!foreach is currently not actually used anywhere in trunk, but I
plan to use it in the AMDGPU backend. If out-of-tree targets are
using it, they can adjust to the new syntax very easily.
Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits, tpr
Differential Revision: https://reviews.llvm.org/D43651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326705 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The intention is to allow us to more easily restructure how resolving is
done, e.g. resolving multiple variables simultaneously, or using the
resolving mechanism to implement !foreach.
Change-Id: I4b976b54a32e240ad4f562f7eb86a4d663a20ea8
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43564
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326704 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
NAME has already worked for def in a multiclass, since the (protoype)
record including its NAME variable is created before parsing the
superclasses. Since defm's do not have an associated single record,
support for NAME has to be implemented differently here.
Original test cases provided by Artem Belevich (tra)
Change-Id: I933b74f328c0ff202e7dc23a35b78f3505760cc9
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43656
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326700 91177308-0d34-0410-b5e6-96231b3b80d8
It is redundant with the implementation in TypedInit.
Change-Id: I8ab1fb5c77e4923f7eb3ffae5889f0f8af6093b4
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43678
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326061 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
FieldInit will just rely on the standardized resolving mechanism to give
us DefInits for folding, thus simplifying the code.
Unlike the removal of resolveListElementReference, this shouldn't have
performance implications, because DefInits do not recurse inside their
record.
Change-Id: Id4544c774c9d9ee92f293615af6ecff706453f21
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43563
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326060 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Resolving a VarListElementInit should just resolve the list and then
take its element. This eliminates a lot of duplicated logic and
simplifies the next steps of refactoring resolveReferences.
This does potentially cause sub-elements of the entire list to be
resolved resulting in more work, but I didn't notice a measurable
change in performance, and a later patch adds a caching mechanism that
covers at least the common case of `var[i]` in a more generic way.
Change-Id: I7b59185b855c7368585c329c31e5be38c5749dac
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43562
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326059 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r325884.
Clang's TableGen has dependencies on the exact ordering of superclasses.
Revert this change fully for now to fix the build.
Change-Id: Ib297f5571cc7809f00838702ad7ab53d47335b26
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325891 91177308-0d34-0410-b5e6-96231b3b80d8
A subsequent change intends to remove resolveListElementReference
entirely. This part of the removal can be split out for better
bisectability.
Change-Id: Ibd762d88fd2d1e2cc116a259e2a27a5e9f9a8b10
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43561
Change-Id: Ifb695041cef1964ad8a3102f448249501a9243f0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325886 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Only check whether the left-hand side type is a subclass (or equal to)
the right-hand side type.
This requires a further fix in handling !if expressions and in type
resolution.
Furthermore, reverse the order of superclasses so that resolveTypes will
find a least common ancestor at least in simple cases.
Add a test that used to be accepted without flagging the obvious type
error.
Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325884 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Returns the size of a list. I have found this to be rather useful in some
development for the AMDGPU backend where we could simplify our .td files
by concatenating list<LLVMType> for complex intrinsics. Doing so requires
us to compute the position argument for LLVMMatchType.
Basically, the usage is in a pattern that looks somewhat like this:
list<LLVMType> argtypes =
!listconcat(base,
[llvm_any_ty, LLVMMatchType<!size(base)>]);
Change-Id: I360a0b000fd488d18bea412228230fd93722bd2c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits, tpr
Differential Revision: https://reviews.llvm.org/D43553
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325883 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Both of these errors should have been caught by type-checking during
parsing.
Change-Id: I891087936fd1a91d21bcda57c256e3edbe12b94d
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325800 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Perhaps the distinction between the two should be removed entirely
in the long term, and the [{ ... }] syntax should just be a convenient
way of writing multi-line strings.
In the meantime, a lot of existing .td files are quite relaxed about
string vs. code, and this change allows switching on more consistent
type checks without breaking those.
Change-Id: If85e3e04469e41b58e2703b62ac0032d2711713c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43557
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325799 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are no new test cases, but a subsequent patch will introduce
assertions that would be triggered by existing test cases without this
fix.
Change-Id: I6a82d4b311b012aff3932978ae86f6a2dcfbf725
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325798 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In the case of !foreach(id, input-list, transform) where the type of
input-list is list<A> and the type of transform is B, we now correctly
deduce list<B> as the type of the !foreach.
Change-Id: Ia19dd65eecc5991dd648280ba6a15f6a20fd61de
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43555
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325797 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This way, it should work even with complex operands.
Change-Id: Iaccf5bbb50bd5882a0ba5d59689e4381315fb361
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43554
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325796 91177308-0d34-0410-b5e6-96231b3b80d8
* !foreach on lists didn't evaluate operands of the RHS operator.
This made nested operators silently fail.
* A typo in the code could result in a wrong value substituted
for an operation which produced a false '!foreach requires an operator' error.
* Keep recursion over the DAG within ForeachHelper. This simplifies
things a bit as we no longer need to pass the Type around in order
to prevent recursion.
Differential Revision: https://reviews.llvm.org/D43083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324758 91177308-0d34-0410-b5e6-96231b3b80d8
