Stefan Behnel wrote: 
>Hi,
>
>Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> cdef object x
>> cdef int a, b
>> a = b = x # currently x gets converted twice, but one could imagine 
>> wanting to optimize so that it happens only once...
> 
> Two options: you either do it before/as part of the splitting up, as in:
> cdef int i, j
> x = i = j = somecall()
> 
> turns into
> cdef object tmp1
> cdef int tmp2
> tmp1 = somecall()
> x = tmp1
> tmp2 = tmp1
> i = tmp2
> j = tmp2
> 
> Option 2: you realize that your time is better spent at optimizing the
> general case that could arise if one wrote the thing using seperate
> assignments (it is still optimizeable in theory) and stick a (much more
> advanced) algorithm after the splitting up, where it can benefit more
> assignment types.
>
>I disagree with option 2. A statement like
>
>    a = b = xyz
>
>is very clearly asking for "xyz" being evaluated once, while
>
>    a = xyz
>    b = xyz
>
>is explicit about evaluating "xyz" twice (whatever xyz actually is). The code 
>we currently generate for the first statement (at least in some cases) is 
>surprising, while in the second case it matches my expectations.
>
>Also, I expect the logic required to determine that two statements assign the 
>same thing to different names to be non-trivial. Why should the above be 
>optimised, but not
>
>    a = xyz
>    c = zyx
>    b = xyz
>

:-)

This was mostly to demonstrate how you would pick different places in the 
pipeline for different kinds of approaches (to counter the "loose information" 
argument) rather than an actual suggestion.

(I realize there's a lot of examples, but when discussing this kind of grand 
overreaching design I think it is ok, these kind of scenarios help pushing the 
design and see how the design itself "performs").

(But I meant to (hypothetically) imply that your latter example would also be 
optimized.. I am assuming we are talking about calls to PyxFromLong etc. here, 
not anything with possible side-effects.)

Dag Sverre

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to