On Thu, Aug 21, 2014 at 10:42 AM, Prathamesh Kulkarni
<bilbotheelffri...@gmail.com> wrote:
> On Tue, Aug 19, 2014 at 4:35 PM, Richard Biener
> <richard.guent...@gmail.com> wrote:
>> On Tue, Aug 19, 2014 at 12:18 PM, Prathamesh Kulkarni
>> <bilbotheelffri...@gmail.com> wrote:
>>> I was wondering how to write transform that involves conversions
>>> (without using c_expr) ?
>>> for eg:
>>> (T1)(~(T2) X) -> ~(T1) X
>>> // T1, T2 has same precision and X is an integral type not narrower than
>>> T1, T2
>>>
>>> this could be written as:
>>> (simplify
>>> (convert (bit_not (convert@0 integral_op_p@1)))
>>> if-expr
>>> transform)
>>>
>>> How would the transform be written ?
>>> with c_expr we could probably write as: (is that correct?)
>>> (bit_not { fold_convert (type, @1); })
>>
>> No, unfortunately while that's correct for GENERIC it doesn't work
>> for GIMPLE code-gen. c_exprs are required to evaluate to
>> "atomics", that is, non-expressions.
>>
>>> I was wondering whether we should have an explicit support for
>>> conversions (something equivalent of "casting") ?
>>> sth like:
>>> (bit_not (cast type @0))
>>
>> Indeed simply writing
>>
>> (bit_not (convert @1))
>>
>> will make the code-generator "convert" @0 to its own type
>> (I knew the hack to simply use the first operands type is not
>> going to work in all cases... ;). Other conversion operators
>> include FIX_TRUNC_EXPR (float -> int), FLOAT_EXPR
>> (int -> float).
>>
>> For most cases it works by accident as the outermost expression
>> knows its type via 'type'.
>>
>> In the cases where we need to specify a type I'd like to avoid
>> making the type-converting operators take an additional operand.
>> Instead can we make it use a operator flag-with-argument? Like
>>
>> (bit_not (convert:type @1))
>>
>> or for the type of a capture (convert:t@2 @1).
>>
>> We can also put in some more intelligence in automatically
>> determining the type to convert to. In your example we
>> know the bit_not is of type 'type' and this has to match
>> the type of its operands thus the 'convert' needs to convert
>> to 'type' as well. I'm sure there are cases we can't
>> auto-compute though, like chains of conversions (but not sure
>> they matter in practice).
>>
>> So let's try that - Micha will like more intelligence in the generator ;)
>>
>> I suggest to add a predicate to the generator conversion_op_p
>> to catch the various converting operators and then assert that
>> during code-gen we are going to create it with 'type' (outermost
>> type), not TREE_TYPE (ops[0]). Then start from the cases
>> we want to support and special-case (which requires passing
>> down the type of the enclosing expression).
> Um sorry, I am not sure if I understood that correctly.
> How would conversion_op_p know when to use 'type' and not TREE_TYPE (ops[0]) ?
> conversion_op_p would be used somewhat similar to in the attached
> patch (illustrate only) ?Yeah, kind of. Attached is my try which handles (bit_not (convert (plus @0 (convert @1)))) fine (converting @1 to the type of @0) but obviously not (convert (convert @1)) which is impossible to auto-guess and not (bit_not (convert (plus (convert @0) @1))) though that can be made work by first generating code for @1 and then for (convert @0) so it can access the type of @1 to convert to its type. I'll give the patch proper testing and will install it. Thanks, Richard. > Thanks, > Prathamesh >> >> Thanks, >> Richard. >> >>> in case we want to cast to a type of another capture >>> we could use: >>> (foo (cast (type @0) @1)) ? // cast @1 to @0's type >>> here type would be an operator that extracts type of the capture. >>> >>> Another use of having type as an operator I guess would be for >>> type-matching (not sure if it's useful). >>> for instance: >>> (foo (bar @0 @1) @(type @0)@1) >>> that checks if @0, @1 have same types. >>> >>> I was wondering on the same lines if we could introduce new >>> keyword "precision" analogous to type ? >>> (precision @0) would be short-hand for >>> TYPE_PRECISION (TREE_TYPE (@0)) >>> >>> So far I found couple patterns in fold_unary_loc with conversions >>> in transform: >>> (T1)(X p+ Y) into ((T1)X p+ Y) >>> (T1)(~(T2) X) -> ~(T1) X >>> (T1) (X * Y) -> (T1) X * (T1) Y >>> >>> Thanks, >>> Prathamesh
p2-2
Description: Binary data
