On Fri, Aug 18, 2017 at 4:37 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote:
>> My idea/question is the following: this interpretation
>> is already done for all 'normal' values. So couldn't we
>> consider the context as a special kind of 'variable',
>> use a normal pseudo for it, use phi-nodes on them and
>
> Question. What syntax are you considering for declare
> this special pseudo? Does it automatically attach to the
> variable that has the context attribute?
First, it's only a vague idea. Soaking since a little while
but still only a vague idea.
You don't need at this point a special syntax.
For example, the return value is currently stored in a special
variable/symbol: 'return' in a special namespace/scope.
>> let the normal simplification process act on them?
>> If the context is (proveably) well balanced, there
>> shouldn't be any phi-node left for this context.
>
> Assume you do the context pseudo attach to the lock
> variable. Then you will have to do the pointer alias properly.
> People might have different pointer point to that variable.
No no, it's not the point here.
What I meant in the idea is that currently OP_CONTEXT
and its associated attribute work with a unique implicit
'object', called 'context' but not explicitly associated to
a symbol/variable and thus they need their own specific
machinery.
>> I'm not sure if there would be any significant advantage,
>> but it seems to me that what is currently done is
>> somehow redundant with the 'normal' processing.
>> It could also maybe help to have several independent
>> contexts.
>
> 'normal' process do you mean the context statement?
No, the processing of variables and pseudos.
>> [of course, we can't really use add/sub for the context
>> increase/decrease as we want to check if the context
>> don't become negative].
>
> It can become negative for some helper function that
> wrap around the unclock function.
This need to be checked (and currently there is a small gap
where it can go negative and positive again and not warned
about it.
> I think the biggest problem with context right now is actually
> not able to inline or take into account for the function that
> change the context. We can add more context attribute to
> the function to describe what this function might do to the
> context. The best way is automatic to make this happen. I see
> that as the biggest cause of the false alarm on context warnings.
There are several problems here:
1) the false alarms. These are unavoidable, it's equivalent to the
halting problem. We can only be correct and precise in restricted
situations (no loops, for example). It's not what the idea here is about.
2) what you describe here about the inlines.
The underlying problems is to match the 'names/expression'
given in the declarations with the ones used in(side) the definition.
I've some drafts but I'm not totally sure about what exactly can be
done.
3) because of 2) we ignore all the names and we simply care about
the sum of all contexts.
So, in truth, we can only deal with a single context.
4) the duplicated machinery this idea/question is about.
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
