It seems hsa_ext_amd.h should define hsa_amd_memory_lock and hsa_amd_memory_unlock according to https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/master/src/inc/hsa_ext_amd.h

In D115279#3178496, @ye-luo wrote:

hsa_amd_memory_lock and hsa_amd_memory_unlock are missing in hsa.cpp and hsa_ext_amd.h as well under openmp/libomptarget/plugins/amdgpu/dynamic_hsa

Hi, @dmgreen With this patch, the llc command crashed. Would you take a look?
llc -mcpu=core-avx2 main.ll

In D111688#3074036, @craig.topper wrote:

In D111688#3062166, @MatzeB wrote:

huh... I guess the problem here was that we interpreted the register numbers as plain unsigned... And virtual registers always have bit 31 set, so I guess the bitset could indeed grow to unreasonable sizes.

• Please try if DenseSet<Register> works too.
• If you can please find a shorter more succinct title.

Then we should be good to land this.

SparseBitVector shouldn't be effected by bit 31 being set. It stores 128 bit chunks of bits in a linked list. Insertion does a linear scan forward or backward from the most recently accessed chunk to trying to find the chunk to insert in. Were we accessing it in some pathologically bad way that caused long linear scans?

If the issue is with the inserting function, then the title of this patch is misleading. The number of kill flags in is irrelevant. The place where the insert happens doesn't know how many kill flags exist. Only the later call to MRI->clearKillFlags(I) would know that.

Replace DenseSet<unsigned> with DenseSet<Register>

In D111688#3060458, @pengfei wrote:

In D111688#3060447, @yubing wrote:

In D111688#3060446, @pengfei wrote:

How do you calculate the kill flags handling time?

I am using std::chrono::high_resolution_clock::now()

std::chrono::high_resolution_clock::time_point start = std::chrono::high_resolution_clock::now();
RegsToClearKillFlags.insert(MO.getReg()); // Remember to clear kill flags.
std::chrono::duration<double, std::milli> duration = std::chrono::high_resolution_clock::now() - start;

Do you also calculate the time of all the access to RegsToClearKillFlags?

In D111688#3060446, @pengfei wrote:

How do you calculate the kill flags handling time?

I am using std::chrono::high_resolution_clock::now()

use DenseSet<unsigned> instead, please ignore previous patch

Solve the lit testcases fail

LGTM

Hi, @lebedev.ri .

1. I think https://reviews.llvm.org/D105390 also has the same issue where you might create X86ISD::VBROADCAST(128->256) in AVX.
2. Besides, Before https://reviews.llvm.org/D105390, we have nicer asm output for the testcase we added:

Bring back getRowFromCol

Address flanhn and yuanke's comments

Rebase

Address yuanke's comments

Just a rebase

Address buildfail in https://lab.llvm.org/buildbot#builders/77/builds/5053

It seems there is buildfail, I will revert it and fix bugs.
https://lab.llvm.org/buildbot#builders/77/builds/5053

Address Pengfei's comments

Rebase after https://reviews.llvm.org/D98773 is merged.

address Pengfei's comments

In D93594#2628497, @nikic wrote:

It looks like this has caused a compile-time regression at O0: https://llvm-compile-time-tracker.com/compare.php?from=9341bcbdc93a251b632ffaa51a84452a7a4a5e4e&to=4f198b0c27b04e830a3069aaf4b39cf203eaae4a&stat=instructions

The cause is probably the computation of DomTree and LoopInfo, even if no AMX intrinsics are present. I think you should be able to easily fix this by not fetching DT/LI from the pass manager, and computing them in the pass instead (only if intrinsics are present).

just do a rebase

Fix buildfail when it is -DBUILD_SHARED_LIBS=ON

In D93594#2606157, @RKSimon wrote:

@yubing I've reverted this as it was failing on a lot of buildbots: http://lab.llvm.org:8011/#/builders/109/builds/9867

Thanks all for reporting and reverting this. I will do bugfix asap.

Address pengfei's comments

address comments above

Fix some comments and commit message

Modify some comments

Fix incorrect naming for dpbf16's bb