LGTM. Please hold on some days for other reviewers. Thanks for adding this support.

Thanks for fixing this. LGTM

Maybe I am misunderstanding the relocation fixups and DQ form instructions, if so, please ignore my comments. : )

gentle ping

In D114778#3226718, @qiucf wrote:

nit: Rename debug-label-fast-isel.ll to debug-label-fast-isel-xcoff.ll?

comment address

gentle ping

LGTM. Thanks for the explanation.

If to apply all the reverted patches (D114705, D113741, and D113743) I believe you should see a correct DWARF compiled for your example.

In D113741#3210838, @dblaikie wrote:

In D113741#3210175, @shchenz wrote:

To continue with a more accurate fix, one example for your reference. (The behavior is changed with/without this reversion):

Sorry, I'm not following this comment ^ (& the rest) - could you rephrase if there's a question/concern you have I can help clarify/describe/work with you on?

To continue with a more accurate fix, one example for your reference. (The behavior is changed with/without this reversion):

int main() {      // <====== function scope
  int x = 3;
  int num = 6;
  printf("%d\n", x);
  if (num) {   // <======= lexical block 1
    static int x = 45;
    printf("%d\n", x);
    if (x) {   // <======= lexical block 2
      int x = 145;
      printf("%d\n", x);
    }
  }
  return 0;
}

Look almost good! Thanks for doing this.

In D116053#3203538, @rampitec wrote:

I am not sure I can prove to myself this is legal. For example you are sinking a def into a loop with divergent condition and this def is used after the loop. Can this happen?

gentle ping

rebase for D116092

In D115503#3199459, @Esme wrote:

In D115503#3195171, @dblaikie wrote:

Ah, cool - could you include % growth on those rows

Thanks, I edited the table in the previous comment.

(hmm, .debug_line and .debug_str shouldn't be changing in size with this change, right? If you use the same clang version to test the two cases (if you're using a bootstrap with/without the patch applied, then the patch changes itself would show up as changes here))

Hmm...it's a little strange. I got these data by:

1. pull a base llvm-project branch --> source codes
2. build the source --> clang1
3. build the codes after applying the patch --> clang2
4. use clang1 to build the source (no patch) --> clang-before
5. use clang2 to build the source (no patch) --> clang-after
6. compare the size between clang-before and clang-after

I reproduced these steps on another base branch, and saw similar changes (i.e. .debug_line and .debug_str changed in size)...
But I think the change is so small as to be negligible?

& if you could include this table in the commit message, that'd be great!

(can you commit this yourself, or do you need someone to do that for you?)

I will include this table when committing, thanks!

LGTM. Thanks for adding this support.

In D114419#3197868, @jsji wrote:

Can you try adding a testcase for Os or Oz to see what happens? I suspect that this change might override the pref alignment settings in Lowering.

There is a case test_minsize() in file test/CodeGen/PowerPC/code-align.ll, there is no change for that case, so I think there should be no change for the loop alignment after this patch?

LGTM. Thanks

In D114419#3189763, @jsji wrote:

Do we have any data about the *size* change due to alignment change? especially for code with lots of small functions, like perlbench?

address comments

Thanks for fixing this. LGTM. Please wait for @dblaikie comments.

gentle ping

gentle ping

In D111485#3175267, @jsji wrote:

LGTM since you have already double checked the compatiblity.

Thanks for your review @nemanjai

I asked for some help from a GCC developer. He told me GCC only copies byval structure bigger than 64 bytes to the parameter save area instead of 8 bytes for ELF64. So now after the change, clang should have the same logic as GCC.

gentle ping

gentle ping

gentle ping

So for this patch, we need to wait for ARM experts find out the solution for the overflow issue when ExitCount type is same with CountType?

LGTM too. Thanks for cleaning up.

Can we fix this at the place where MFVSRLD is generated? (in DAG-ISEL?)

address comments

https://reviews.llvm.org/D114778 is created for the root cause, so I think we can abandon this patch now?

https://reviews.llvm.org/D114778 is created for the root cause, so I think we can abandon this patch now?

LGTM. Please be aware that we are working on resolving this in fast-isel for 64-bit XCOFF.

gentle ping

gentle ping

In D114419#3148440, @nemanjai wrote:

Just out of curiosity, if the csect that contains a function is aligned at 2 bytes, how do we ensure loops within those functions are aligned at 32 bytes?

LGTM. Thanks

Thanks. LGTM. Please hold on some days in case other reviewers like @craig.topper have further comments.

A patch like this should be marked with "NFC" in the title

If we make the SimplifyCFG pass keep the statically calculated branch weights(if any) for the select instructions, will our case be optimized like expected in the CGP pass? If so, I think letting SimplifyCFG pass keep the branch weights for the select instructions should make more sense. I saw there are some functions like setBranchWeights in SimplifyCFG pass that will update the branch weights, but not sure why it does not work for our case.

In D114110#3147660, @stevewan wrote:

Dumb question, where is the dwarf version specified?

gentle ping

for power 9, use lxsibzx as it has the same latency with lvx but has more useable registers.

LGTM. Thanks

LGTM.

This seems like the same/similar semantic with PPCInstPrinter::getMnemonic()?

NFC patch 7c6f5950f08d41017536575152fb765ba85a09a1 is committed for the required comments.