♟ rampitec

Please do not forget to add llvm-commits.

Patch does not take control flow divergence into account.

[AMDGPU] hazard recognizer for fp atomic to s_denorm_mode

In D63619#1553498, @arsenm wrote:

LGTM assuming the DS atomics really aren't impacted

LGTM, except one indent.

[AMDGPU] gfx10 tests. NFC.

[AMDGPU] gfx1010 core wave32 changes

Virtualize TargetInstrInfo::getRegClass()

In D63205#1546855, @rampitec wrote:

In D63205#1546727, @bogner wrote:

Maybe I'm missing something, but the override implemented in D63204 looks like a subset of the default TII::getRegClass that falls through to TRI::getRegClass, just like the default does. Is this change actually necessary?

It will fallback to TRI::getRegClass(), but to the base class of it through the pointer to TRI in the InstrEmitter, so call goes to the default implementation. Either TII::getRegClass() needs to be virtual or TRI::getRegClass().
I have preferred to override in TII because it is called less frequently than from TRI.

[AMDGPU] gfx10 wave32 patterns

In D63494#1548974, @rtaylor wrote:

In D63494#1548719, @rampitec wrote:

Can we have a disasm test? I want to see that we do not mess with decoding.

Something other than the -disassemble checks?

[AMDGPU] gfx1010 disassembler changes for wave32

In D63489#1548470, @lebedev.ri wrote:

In D63489#1548451, @alex-t wrote:

In D63489#1548288, @lebedev.ri wrote:

This causes generation of incorrect code in AMDGPU backend.

This sounds like some other check is missing elsewhere?
What happens if you feed it such an ir as-if after this transform, but manually written?
("that will result in broken asm/crashes" is hopefully not the answer)

That being said, why is LCSSAPass not sufficient?
It's already supposed to undo transforms like this.

It will result in syntactically correct asm and no crashes. In runtime we'll get incorrect result though :)
Adding LCSSA pass again later on is difficult in the sense of the pass dependencies.
So, it's better to fix the explicit bug in SimplifyPHI....

Aha, so it's not -instsimplify pass itself, but how it's used during transition into backend.

You certainly don't want to make this blacklist unconditional, it should still run when the -instsimplify pass itself is run. (+instsimplify test)

How does this affect other targets (backends)? Does this need some TLI hook?

Can we have a disasm test? I want to see that we do not mess with decoding.

Tentative LGTM for the code itself. Please check with Brian for feasibility.

Two questions:

Should that only be enabled if xnack enabled? Was it even ever on before gfx9, I think no?
Should we support it on ASICs older than gfx9? This may be more a question to Brian.

Rebased and removed unused S_ADDC_U64_PSEUDO/S_SUBC_U64_PSEUDO.

[AMDGPU] Use custom inserter for gfx10 VOP2b

[AMDGPU] gfx1010 subvector test. NFC.

LGTM if precheckin will succeed for this and for D63456.

[AMDGPU] Propagate function attributes thru bitcasts

LGTM, but please run precheckin before submit. Same for D63225 if you sure dest is always virtual.

[AMDGPU] Propagate function attributes thru bitcasts

In D63205#1546727, @bogner wrote:

Maybe I'm missing something, but the override implemented in D63204 looks like a subset of the default TII::getRegClass that falls through to TRI::getRegClass, just like the default does. Is this change actually necessary?

[AMDGPU] gfx1010 wavefrontsize intrinsic folding

[AMDGPU] Pass to propagate ABI attributes from kernels to the functions

Rebased. Reenabled HSA metadata test disabled with previous commit due to dependency.

[AMDGPU] gfx1010 wave32 metadata

Rebased to master and disabled one run line in the hsa-metadata-kernel-code-props-v3.ll to decouple the change from parent chain. That should complete support for wave64 at least until D63205 is submitted.

rampitec (Stanislav Mekhanoshin)
User

Projects

User Details

Recent Activity
View All

Yesterday

Fri, Jun 21

Thu, Jun 20

Wed, Jun 19

Tue, Jun 18

Mon, Jun 17

rampitec (Stanislav Mekhanoshin)User