[Mesa-dev] [PATCH 1/2] gm107/ir: make use of FADD32I for all immediates

Samuel Pitoiset samuel.pitoiset at gmail.com
Tue Jun 28 08:33:56 UTC 2016



On 06/28/2016 05:10 AM, Ilia Mirkin wrote:
> On Mon, Jun 27, 2016 at 6:08 PM, Samuel Pitoiset
> <samuel.pitoiset at gmail.com> wrote:
>>
>>
>> On 06/28/2016 12:06 AM, Ilia Mirkin wrote:
>>>
>>> On Mon, Jun 27, 2016 at 6:05 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>
>>>> On Mon, Jun 27, 2016 at 6:04 PM, Samuel Pitoiset
>>>> <samuel.pitoiset at gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 06/28/2016 12:02 AM, Ilia Mirkin wrote:
>>>>>>
>>>>>>
>>>>>> This loses you saturation. Does the target account for this?
>>>>>
>>>>>
>>>>>
>>>>> No saturate flag for FADD32I.
>>>>
>>>>
>>>> That's not what I asked.
>>>
>>>
>>> Specifically look at this code:
>>>
>>> bool
>>> TargetNVC0::isSatSupported(const Instruction *insn) const
>>> {
>>>    if (insn->op == OP_CVT)
>>>       return true;
>>>    if (!(opInfo[insn->op].dstMods & NV50_IR_MOD_SAT))
>>>       return false;
>>>
>>>    if (insn->dType == TYPE_U32)
>>>       return (insn->op == OP_ADD) || (insn->op == OP_MAD);
>>>
>>>    // add f32 LIMM cannot saturate
>>>    if (insn->op == OP_ADD && insn->sType == TYPE_F32) {
>>>       if (insn->getSrc(1)->asImm() &&
>>>           insn->getSrc(1)->reg.data.u32 & 0xfff)
>>>          return false;
>>>    }
>>>
>>> Note how it will say that sat is supported for SIMMs with FADD? So the
>>> compiler will generate those ops, but then the emitter won't be able
>>> to handle it.
>>>
>>
>> Okay, I get it.
>
> By the way, instead of trying to fight the longIMMD, you should just fix it -
>
>         /*0008*/               @P0 FADD R0, R0, 1.NEG;      /*
> 0x3858203f80000000 */
>
> which corresponds nicely to
>
>       emitNEG(0x2d, insn->src(1));
>
> The issue is that emitIMMD does
>
>    if (len == 19) {
> ...
>       emitField( 56,   1, (val & 0x80000) >> 19);
>       emitField(pos, len, (val & 0x7ffff));
>
> So the problem is that the 56 isn't as fixed as the emission code had
> hoped. I suspect that adjusting it will fix all these silly cases.
>
>   -ilia
>

         /*0010*/               @P0 FADD R0, R0, 0.NEG;      /* 
0x3858200000000000 */
         /*0010*/               @P0 FADD R0, R0, -0;      /* 
0x3958000000000000 */

urgh?

-- 
-Samuel


More information about the mesa-dev mailing list