[dragonegg PATCH] Implement __builtin_signbit

Duncan Sands baldrick at free.fr
Fri Jun 28 04:41:11 PDT 2013


Hi Peter,

On 28/06/13 00:25, Peter Collingbourne wrote:
> On Thu, Jun 27, 2013 at 08:51:21PM +0200, Duncan Sands wrote:
>> Hi Peter,
>>
>>>>> +      return Builder.CreateZExt(Result,
>>>>> +                                ConvertType(gimple_call_return_type(stmt)));
>>>>
>>>> I think the extension type should be based on the signedness of the return type,
>>>> rather than assuming it is an unsigned type.
>>>
>>> Result is an i1, so zero extension should cause us to return 0 or 1
>>> (consistent with GCC) regardless of the signedness of the return type.
>>
>> it does look like GCC only cares about 0 or no-zero.  In which case I'm OK with
>> this.  That said, it could be more efficient.  For example, if the input type is
>> float, and the output i32, then you can just and with a mask that only keeps the
>> sign bit, reducing from bitcast+icmp+zext to bitcast+and.  What do you think of
>> doing a bitcast, an "and" to only keep the sign bit, then
>>    - if the result is wider than the float, a zext
>>    - if the result is the same size as the float, nothing
>>    - if the result is smaller than the float, right shift the bit into the
>> top bit of the result
>
> 'd be wary of making such a change, not only to stay consistent with
> GCC

actually this is more or less what GCC expands the builtin to if the target
doesn't handle it.

  and Clang, but because IR instruction count isn't necessarily
> correlated with machine instruction count.  In particular, x86 has
> the MOVMSKPD and MOVMSKPS instructions which can be selected for the
> code this function generates while it would take another instruction
> for the scheme you describe.  I also don't think this intrinsic will
> come up often enough for us to care too much about performance so
> I'm tempted to leave this as is.

Fair enough.

Ciao, Duncan.




More information about the llvm-commits mailing list