Addressed comments

Addressed comments

Fixed

Addressed

Fixed

Addressed comments

Ping. Rebase.

Updated

Addressed @ABataev's comments.

Update. Splitted findBuildAggregate() to recursive and non-recursive parts.

In D83779#2153039, @ABataev wrote:

In D83779#2150568, @xbolva00 wrote:

Add test?

I assume this is actually NFC, it just tries to optimize the function findBuildAggregate.

Update tests

In D83779#2150568, @xbolva00 wrote:

Add test?

In D74516#1913475, @fedor.sergeev wrote:

I'm sorry for the late comment, but this should have really been done through the PassInstrumentation framework.
It looks like a classic use-case.

Here is the another patch for new pm support: D74516

I've faced with objections from @philip.pfaffe trying to implement the same: D62067. Since that time, trace profiler has supported multiple threads (D71059), so I do believe this can now correctly work. I would wait for review from new pm guys.

In D72689#1819130, @xbolva00 wrote:

I saw similar thing in recent research

https://www.nextgenvec.org/slides/revec-cc.pdf

They proposed a new compiler pass to perform revectorization.

Did you look at it? What do you think?

Update AAMDNodes constructors

Ping!

Gently ping again.

Gently ping. Is it ok now?

In D70924#1782238, @hfinkel wrote:

In D70924#1780145, @anton-afanasyev wrote:

Hi @hfinkel, I've investigated the current state of TBAA support in LLVM. AFAIU (see D40975, but it is still uncommited) the new format of tbaa tag replaces tbaa.struct tag. Does it mean tbaa.struct tag will be deprecated soon?

It might, but it depends on the progress on the new TBAA format. This is not a large change, and I think that we can proceed with this regardless.

Can you please explain what will end up using this information? That should be present in the description.

Fix

In D70924#1780145, @anton-afanasyev wrote:

Hi @hfinkel, I've investigated the current state of TBAA support in LLVM. AFAIU (see D40975, but it is still uncommited) the new format of tbaa tag replaces tbaa.struct tag. Does it mean tbaa.struct tag will be deprecated soon?

Starting from D71059 time profiler supports multiple threads, this is a step to support new PassManager.
Regarding note about "why not to use new PM infrastructure for whole time profiler?" The current implementation of time profiler is independent and used by frontend (clang) and ThinLTO (lld). It is rather simple to use by adding just one line at the start of the profiled scope. I'm not sure new PM infrastructure is appropriate for it.

Commited long time ago (https://reviews.llvm.org/rL373142).

Fixed

Updated getAAMetadata() with Merge=true

Hi @hfinkel, I've investigated the current state of TBAA support in LLVM. AFAIU (see D40975, but it is still uncommited) the new format of tbaa tag replaces tbaa.struct tag. Does it mean tbaa.struct tag will be deprecated soon?

LGTM

In D71059#1776893, @russell.gallop wrote:

In D71059#1776620, @anton-afanasyev wrote:

Btw, is it planned to add test for multithreading?

Thanks for the review.

There are tests for multi-threaded ThinLto using this within LLD in the next review (https://reviews.llvm.org/D71060).

Were you thinking of this, or of unit tests?

Btw, is it planned to add test for multithreading?

LGTM, thanks!

Fix typo

Ping

Comment fix

Fixed

Fix comment

Fixed

Continuation of https://reviews.llvm.org/D70068. I've merged findBuildVector() and findBuildAggregate() to one findBuildAggregate() function making it recursive to recognize multidimensional aggregates. Aggregates required to be homogeneous.

Here is further enhencement considering different combinations of aggregates: https://reviews.llvm.org/D70587

Updated

In D70068#1755110, @RKSimon wrote:

Please can you pre-commit the tests with current codegen and then rebase to show the diff?

Updated test diff against precommitted tests

Is it ok to lgtm for now?

Added test for {{{i16,i16},{i16,i16}},{{i16,i16},{i16,i16}}}.
I'm to process this and other previously added test cases by the following commit.

Added several tests

In D70068#1748108, @vporpo wrote:

...
But could you also add some more tests to show which of these cases this patch is taking care of. For example, I think {<2 x float>, <2 x float>, <4 x float>} or {<2 x float>, float, float} will not work. Here are some examples:
...

Yes, thanks, I'm to add two tests for homogeneous and non-homogeneous cases.

In D70068#1748108, @vporpo wrote:

Well, ideally we should be able to handle any combination and nesting of scalars, vectors and aggregates in a unified way.
For example:

{float, <2 x float>, float},
{float, float, <2 x float>},
{{float, float}, <4 x float>, <2 x float>},
{{float}, {float}, [2 x float]}, 
{{{float, float}, float}, float}

etc.
This would require some redesign of the code, which is why I think it makes sense to have a single patch for all of them.

But yes, feel free to split them into separate patches.

Update test with shorter one

In D70068#1746753, @vporpo wrote:

I think we cannot handle several similar cases with aggregates inside aggregates (e.g., [2 x {float, float}], {{float, float}, {float, float}}). Perhaps we could address some of these cases too with this patch? Please see the tests below:
...

Update