[PATCH 42/55] rs6000: Handle gimple folding of target built-ins

Bill Schmidt wschmidt@linux.ibm.com
Mon Aug 2 13:31:43 GMT 2021


Hi Will,

On 7/29/21 7:42 AM, Bill Schmidt wrote:
> On 7/28/21 4:21 PM, will schmidt wrote:
>> On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
>>
>>
>> +    /* Vector compares; EQ, NE, GE, GT, LE.  */
>> +    case RS6000_BIF_VCMPEQUB:
>> +    case RS6000_BIF_VCMPEQUH:
>> +    case RS6000_BIF_VCMPEQUW:
>> +    case RS6000_BIF_VCMPEQUD:
>> +      fold_compare_helper (gsi, EQ_EXPR, stmt);
>> +      return true;
>> +
>> +    case RS6000_BIF_VCMPNEB:
>> +    case RS6000_BIF_VCMPNEH:
>> +    case RS6000_BIF_VCMPNEW:
>> +      fold_compare_helper (gsi, NE_EXPR, stmt);
>> +      return true;
>> +
>> Noting that entries for  _CMPNET,_VCMPEQUT, etc are missing from this
>> version versus the non-new version of this function.
>> I believe thiswas/is deliberate and by design.
>> Same with entries for P10V_BUILTIN_CMPLE_1TI, etc below.
>
> Indeed not!  This is something I missed when new code was added after I
> posted the original patch series.  I'll reinstate the quadword
> compares.  Thanks for spotting this!


Interestingly, when the quadword compares are expanded at GIMPLE time, 
we generate worse code involving individual 64-bit compares.  For the 
time being, I will not expand these at GIMPLE time; independently, this 
bears looking at to see why expressions like (uint128_1 < uint128_2) 
will generate poor code.

Bill

>
> Bill
>


More information about the Gcc-patches mailing list