[PATCH] D61812: [AMDGPU] Fixed handling of imemdiate i1 literals

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 14 08:23:50 PDT 2019


arsenm added inline comments.


================
Comment at: lib/Target/AMDGPU/SIInstrInfo.cpp:2526
   switch (Imm.getBitWidth()) {
+  case 1: // This likely will be a condition code mask.
+    return false;
----------------
arsenm wrote:
> rampitec wrote:
> > arsenm wrote:
> > > arsenm wrote:
> > > > rampitec wrote:
> > > > > arsenm wrote:
> > > > > > I don’t understand where this is coming from. There should be no 1-bit immediates anywhere?
> > > > > Combiner sometimes produces "xor x, true", and even "add x, true". This is not the first time we hit it, we have even implemented lowering.
> > > > I would expect this to be extended to the wavesize during selection
> > > I guess that wouldn't provide much benefit, but this should always be true?
> > Yes, these are extended, but we have the situation where predicate is checked before the extension.
> > 
> > While it technically can fit VOP literal I do not believe that would be a good idea. The bool operand shall go SOP instruction, so I preffered to return false. At the very least we will cancel unsuitable pattern matching earlier this way.
> But SOP instructions have the same inline immediate values. This isn't a property of the immediate or instruction
OK, I see this is breaking not at the point I thought. In the bool case these still end up materialized with regular int64_t operands. This is only happening in the DAG patterns. Saying this is true should be fine, since it still works with the normal immediate folding heuristics.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61812/new/

https://reviews.llvm.org/D61812





More information about the llvm-commits mailing list