This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Rename glc operand type
ClosedPublic

Authored by arsenm on Sep 12 2016, 9:27 AM.

Details

Summary

While trying to add the glc bit to SMEM instructions on VI
with the new refactoring I ran into some kind of shadowing
problem for the glc operand when using the pseudoinstruction
as a multiclass parameter.

Everywhere that currently uses it defines the operand to have the same
name as its type, i.e. glc:$glc which works. For some reason now it
conflicts, and its up evaluating to the wrong thing. For the
real encoding classes,

let Inst{16} = !if(ps.has_glc, glc, ?); was not being evaluated
and still visible in the Inst initializer in the expanded td file.
In other cases I got a a different error about an illegal operand
where this was using { 0 } initializer from the bits<1> glc initializer
instead of evaluating it as false in the if.

For consistency all of the operand types should probably
be captialized to avoid conflicting with the variable names
unless somebody has a better idea of how to fix this.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 71021.Sep 12 2016, 9:27 AM
arsenm retitled this revision from to AMDGPU: Rename glc operand type.
arsenm updated this object.
arsenm added reviewers: tstellarAMD, vpykhtin.
arsenm added a subscriber: llvm-commits.
nhaehnle accepted this revision.Sep 12 2016, 9:35 AM
nhaehnle added a reviewer: nhaehnle.

LGTM

This revision is now accepted and ready to land.Sep 12 2016, 9:35 AM
vpykhtin edited edge metadata.Sep 23 2016, 5:33 AM

I'm not sure I understand what the problem is.

One of the problem I met using "bits" is that it requires explicit bit range inside !if expression, that might be the problem in your case. I fixed it for VOPs but haven't in other places yet. Try changing if to !if(has_glc, glc{0}, 0). Other possible way is to use "bit" instead of "bits<1>".

I'm not sure I understand what the problem is.

One of the problem I met using "bits" is that it requires explicit bit range inside !if expression, that might be the problem in your case. I fixed it for VOPs but haven't in other places yet. Try changing if to !if(has_glc, glc{0}, 0). Other possible way is to use "bit" instead of "bits<1>".

I tried that, but I think I had a different issue with that

vpykhtin accepted this revision.Sep 24 2016, 3:10 AM
vpykhtin edited edge metadata.

Well, I don't mind capitilizing it, it even looks better, please do. From some point it worth to collect the number of ways we workaround tablegen problems. One of it I faced recently is the following construction makes tablegen crash:

class getValue<int a> {

string ret = "";

}

multiclass M <string X = getValue<1>.ret> {
}

getValue as a default initializer for multiclass parameter makes tablegen crash.

Another thought: at some point I realised that I put ? or 0 in different places as a stub for missing operand in encoding, I think we should unify this and use 0 everywhere. What if to try using !if(ps.has_glc{0}, glc{0}, 0)?

Another thought: at some point I realised that I put ? or 0 in different places as a stub for missing operand in encoding, I think we should unify this and use 0 everywhere. What if to try using !if(ps.has_glc{0}, glc{0}, 0)?

Doesn't seem to be helping

arsenm closed this revision.Oct 31 2016, 5:29 PM

r285462