[PATCHES] R600/SI: VI fixes

[Marek Olšák]

On Tue, Jan 13, 2015 at 6:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
>
>> On Jan 13, 2015, at 3:05 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> Are you sure?
>>
>> In a nutshell, getMCOpcode does this:
>>
>> uint16_t x = (uint16_t)-1U;
>> return x;
>>
>> I don't think a sign extension occurs with uint16_t.
>>
>> Marek
>
>
> I thought getMCOpcode returned int16_t, which would be promoted to int for the compare. In any case, -1 doesn’t require knowing the exact type of it

It returns int, but the table where the opcodes are stored is an array
of uint16_t, so both -1 and 65535 are return values meaning a failure,
but they are a different type of failure (-1 = not found, 65335 =
found but the encoding is undefined).

Marek

>>
>>
>> On Mon, Jan 12, 2015 at 10:43 PM, Matt Arsenault
>> <Matthew.Arsenault at amd.com> wrote:
>>> On 01/12/2015 01:32 PM, Tom Stellard wrote:
>>>>
>>>>> +      if (AMDGPUMCInstLower::getMCOpcode(Op32, TRI.ST.getGeneration())
>>>>> == 65535)
>>>
>>> This should compare -1, not the uint16_t value. I don't think this will work
>>> correctly, the sign extended -1 opcode to int for the compare will not work
>>> as expected
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>