@fhahn Ping. Could you confirm?

@Meinersbur Thanks for your review. I'll update the patch.

@fhahn Ping. Could you confirm?

Ping.
@fhahn @asbirlea Is this OK?

In D75594#1927988, @ikitayama wrote:

In D75594#1927959, @kawashima-fj wrote:

Yes, https://github.com/fujitsu/A64FX contains the official microarchitecture information of A64FX. I wanted to include the URL in the Git commit message but the disclosure was not ready for it at the time.

Can you do it at the next commit opportunity as this reference manual should be broadly read by the Arm developer community?

I'm sorry for the late response. I (and my colleague) updated the test.

Update test.

In D93503#2479425, @fhahn wrote:

This seems reasonable to me, as we should only reduce the number of loads executed during PRE. If they are in the same loop, the metadata should stay valid, as we do not access any additional locations.

Would it be possible to add a simple test case where we move a load from a sub-loop into a parent loop?

Simplify the test code.

Thanks for reviews! I'll commit this next week unless other new comment is posted.

Ping.
Can anyone review? Is there an appropriate reviewer?

In D93791#2471417, @tschuett wrote:

Is there a way to specify the maximum or even the set of supported SIMD-widths for SVE cores?

Remove WriteID512 and update comment.

Ping.
I know many people are on holiday this week. If you have time, please review this patch. I'm on holiday from tomorrow.

@yutsumi Thanks. Good catch. I've addressed your comment.

Ping.

Ping.
Can anyone review this fix?

Ping.

Ping.

Ping.
I know many of LLVM developers are busy with the developer's meeting now. When someone has time, please review.

clang-format reported a format error DenseSet<Instruction*> -> DenseSet<Instruction *> (space before *). However, other three places in the same function (and many places in other functions) have the same format. Should I change all places? only my change?, or keep all them unchanged?

In D79549#2027214, @efriedma wrote:

Could you take another look at the testcase for 34760 in particular? That seems similar enough that it should get fixed at the same time.

In D79549#2025775, @efriedma wrote:

I think there are four loop-reroll issues currently open in Bugzilla:

https://bugs.llvm.org/show_bug.cgi?id=34029
https://bugs.llvm.org/show_bug.cgi?id=42267
https://bugs.llvm.org/show_bug.cgi?id=34760
https://bugs.llvm.org/show_bug.cgi?id=41696

Could you check which ones this patch fixes?

Comment is added.

In D54599#1966949, @marco-c wrote:

I wonder if https://reviews.llvm.org/D76206 didn't fix this too

Thanks. I updated the patch to inverted the conditions (if (fd != -1) {).

Ping.

In D75594#1927988, @ikitayama wrote:

In D75594#1927959, @kawashima-fj wrote:

Yes, https://github.com/fujitsu/A64FX contains the official microarchitecture information of A64FX. I wanted to include the URL in the Git commit message but the disclosure was not ready for it at the time.

Can you do it at the next commit opportunity as this reference manual should be broadly read by the Arm developer community?

Yes, https://github.com/fujitsu/A64FX contains the official microarchitecture information of A64FX. I wanted to include the URL in the Git commit message but the disclosure was not ready for it at the time.

The failure of the pre-merge check is the following clang-tidy warning. I modified only indentation of the line, and compiler-rt does not follow variable naming rules in the LLVM coding standard. So it does not have a problem.

@huntergr @dmgreen Thanks for your reviews.

An unnecessary comment line is removed and indentation is aligned.

Thanks for review.

Thanks for a suggestion. I looked around the code and found that the suggested AArch64TargetMachine constructor is the best place because other option values are set there. The updated patch moved the maximum value setting code to that constructor.

In D71688#1807684, @peter.smith wrote:

Apologies for the delay in responding, just come back from vacation. I've checked the implementation against GCC and it looks like it will give the same behaviour. I've got one minor suggestion surrounding the clamping of TLSSize to its maximum value. It looks like it would only need to be done once, is there a convenient place, such as AArch64TargetMachine where it can be done once?

This is the same as gcc? Sounds good.

Directory prefixes were deleted by git show --no-prefix in the previous diff. It is corrected now.