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 test 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

Update summary

Add test

Oops, missed regression test, I'm to add it.

LGTM, thanks!

Yes, I agree. LGTM.

I believe it's better solution, LGTM.

In D68161#1686632, @lebedev.ri wrote:

Oh nice!

I like this.

One more related question - there are two "Frontend" sections, second one appears to consist only of "CodeGen Function"s.
Is that correct? Should they both be in an actual front-end section, and should they be renamed to, i dunno,
"Sema" and "Codegen"? I'm not sure about this, just raising a question.

In D62067#1672835, @lebedev.ri wrote:

With new-pm soon being the default, i'm curious what's the plan with -ftime-trace?
Will it simply turn into a pumpkin? Is there an upcoming patch (along the lines of D62067#1511128)?

Could you please give LGTM?

Hi @nathanchance, @mgehre, fixed here: https://reviews.llvm.org/D66873, please, look at it to commit.

In D63325#1645892, @mgehre wrote:

I'm seeing the same issue Not all CodeGen sections are inside any Frontend section! with python 3.7.1. Json:

check-time-trace-sections.json15 KBDownload

In D63325#1643023, @nathanchance wrote:

Done, thanks for looking into this!

check-time-trace-sections.json14 KBDownload