This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Fix gimple type checking for fixed-point types


On Fri, Jan 2, 2009 at 4:48 PM, Sean D'Epagnier <geckosenator@gmail.com> wrote:
> Hi,
>
> I am working on fixed point stuff at the moment.  In "ISO/IEC TR
> 18037:2004" on page 16:
>
> 4.1.6.2.2   Bitwise shift operators
> Shifts of fixed-point values using the standard << and >> operators
> are defined to be equivalent to
> multiplication or division by a power of two (including the resulting
> rounding and overflow behavior).
> The right operand must have integer type and must be nonnegative and
> less than the total number
> of (nonpadding) bits of the fixed-point operand (the left operand).
> The result type is the same as
> that of the fixed-point operand. An exact result is calculated and
> then converted to the result type in
> the same way as the other fixed-point arithmetic operators.

Oh well.  The patch is ok then if you add some additional wording to the
tree.def documentation of the shifting codes.  Or, at your discretion, you
may want to add new tree codes for fixed-point shifting.

> I personally think that having support for negative shifts is useful,
> but this spec says it isn't supported.

Richard.

>
> Sean
>
> On 1/2/09, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Fri, Jan 2, 2009 at 12:53 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> The new(ish) gimple type-checking code rejects shifts of fixed-point
>>> values, and shifts of vectors of fixed-point values, both of which are
>>> meant to be allowed.  This causes failures in gcc.dg/fixed-point/allop.c
>>> and gcc.dg/fixed-point/binary.c.
>>
>> Huh, they are?  What is the semantic of a shift 1.234 << 2?  Or is it
>> supposed to be
>> a shift of the bit-pattern?  In which case it should be made explicit via
>> VIEW_CONVERT_EXPRs.  Or the frontend should produce multiplications.
>>
>> So I think this is at least non-obvious...
>>
>> Richard.
>>
>>> Tested on mips64el-linux-gnu, where it fixes the above tests.
>>> OK to install?
>>>
>>> Richard
>>>
>>>
>>> gcc/
>>>        * tree-cfg.c (verify_gimple_assign_binary): Allow shifts of
>>>        fixed-point types, and vectors of the same.
>>>
>>> Index: gcc/tree-cfg.c
>>> ===================================================================
>>> --- gcc/tree-cfg.c      2009-01-02 11:41:02.000000000 +0000
>>> +++ gcc/tree-cfg.c      2009-01-02 11:47:23.000000000 +0000
>>> @@ -3477,7 +3477,7 @@ verify_gimple_assign_binary (gimple stmt
>>>     case LROTATE_EXPR:
>>>     case RROTATE_EXPR:
>>>       {
>>> -       if (!INTEGRAL_TYPE_P (rhs1_type)
>>> +       if (!(INTEGRAL_TYPE_P (rhs1_type) || FIXED_POINT_TYPE_P
>>> (rhs1_type))
>>>            || !INTEGRAL_TYPE_P (rhs2_type)
>>>            || !useless_type_conversion_p (lhs_type, rhs1_type))
>>>          {
>>> @@ -3495,7 +3495,8 @@ verify_gimple_assign_binary (gimple stmt
>>>     case VEC_RSHIFT_EXPR:
>>>       {
>>>        if (TREE_CODE (rhs1_type) != VECTOR_TYPE
>>> -           || !INTEGRAL_TYPE_P (TREE_TYPE (rhs1_type))
>>> +           || !(INTEGRAL_TYPE_P (TREE_TYPE (rhs1_type))
>>> +                || FIXED_POINT_TYPE_P (TREE_TYPE (rhs1_type)))
>>>            || (!INTEGRAL_TYPE_P (rhs2_type)
>>>                && (TREE_CODE (rhs2_type) != VECTOR_TYPE
>>>                    || !INTEGRAL_TYPE_P (TREE_TYPE (rhs2_type))))
>>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]