[Cython] Entry.utility_code_definitions vs. Entry.utility_code

Stefan Behnel stefan_ml at behnel.de
Sun Aug 21 14:35:59 CEST 2011


mark florisson, 21.08.2011 12:57:
> On 21 August 2011 12:54, mark florisson wrote:
>> On 21 August 2011 12:31, Stefan Behnel wrote:
>>> is there a reason for having the two?
>>>
>>> The "uc_definition" is set to instances of "CythonUtilityCode" in
>>> UtilityCode.py, whereas the other is used to keep references to
>>> "UtilityCode" instances, but both inject their code in the same way, it
>>> appears. The first also has dedicated support in the pipeline, whereas
>>> support for the latter is spread across the syntax tree nodes.
>>>
>>> It seems cleaner to me to use the first approach, i.e. to simply walk all
>>> used entries at some late point in the pipeline and to inject their utility
>>> code, rather than to leave that responsibility to each node that uses them.
>>>
>>> Anything I misunderstood here? If not, any objections to merging the latter
>>> into the first?
>>
>> That would be fine with me, as long as it meant no modifications to
>> (Cython)UtilityCode or the code in the pipeline, as I have modified
>> all of those in _memview.
>>
>> I see only two cases in ExprNodes of code checking entry.utility_code
>> and using the utilities, though. So if I understand correctly, it's
>> about those few cases?

I see three or four (depending on how you count), and the main one of them 
is in NameNode.analyse_types(), which is way too early in the pipeline.

The current problem with NameNode is that it usually just executes 
calculate_result_code() during code generation (at least for all 
interesting cases), so it has no way to inject utility code at that point.

Also, "scope.entries" and "entry.used" may be outdated at code generation 
time due to dead code removal (for early created entries) and post-analysis 
optimisations.


> The code in the pipeline is tailored for CythonUtilityCode only, so I
> suppose it would need to be modified.

Sure. It would happen at a point between optimisations and code generation, 
and it would walk the whole tree, take a look at all NameNodes and 
AttributeNodes that have entries marked as used, and inject their utility 
code into the environment. AFAICT, the current pipeline step is just a 
special case of that.

I also thought about making that a dedicated "inject_utility_code" or 
"inject_external_code" phase that nodes can interact with, i.e. we'd call a 
method on each node and it would either do nothing or inject some code into 
the global scope. However, that's obviously much more costly and likely not 
needed. Most nodes can just inject their required code during code 
generation themselves. It's mainly a problem with NameNode and friends.


> I believe the _memview branch is
> nearly finished though, so could you wait for that merge? Otherwise
> modifying the pipeline wouldn't be too bad either, it might only give
> a few conflicts.

I think it can wait a little longer.

Stefan


More information about the cython-devel mailing list