Taurre écrivit :
>> En fait je le vois comme une partition de l'espace des objets en n+1
>> ensembles, où n est le nombre de pointeurs restreints. Dans la derni ère
>> partie, les objets peuvent être atteints par différents pointeurs
>> (alias), mais ne peuvent être atteints par l'un quelconque des n
>> pointeurs restreints ou une de leurs dérivations.
> C'est aussi l'image que j'ai en tête, mais le problème c'est que le s
> exemples donné par la Norme ne semble pas tout à fait la suivre. En
> effet, si je reprends mon exemple du début où seul le pointeur "v" est
> qualifié de restreint, dans ce cas on se retrouve avec deux
> partitions: une pour les objets accédés par "v" et une pour les aut res
> (si j'ai bien saisit?).
Oui.
> En suivant cette logique, on pourrait donc
> supposer que l'optimisation aura lieu,
Non. C'est tout l'onjet de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
> cependant elle ne se produira que si tous les pointeurs sont
> qualifiés de restreint...
Euh, là c'est ton analyse du comportement de GCC. GCC est un gros
programme, je n'ai pas les possibilités intellectuelles pour détermin er
son comportement (qui par ailleurs varie avec les versions).
> La même
> analyse peut être appliquée au prototype des fonctions standard:
> pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
> restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
> Je trouve la définition de la Norme franchement floue,
Disons que le style de cette partie tranche assez nettement avec le
reste ; c'est dû en partie au fait que les rédacteurs ne sont pas les mêmes.
> c'est limite si elle ne se contredit pas dans son exemple numero deux
> (6.7.3.1 § 8 p 111) quand elle dit:
>> EXAMPLE 2 The function parameter declarations in the following example
> void f(int n, int * restrict p, int * restrict q)
<snip>
>> assert that, during each execution of the function, if an object is ac cessed through
>> one of the pointer parameters, then it is not also accessed through th e other.
> alors qu'elle dit plus haut (6.7.3 § 7 p 109):
>> An object that is accessed through a restrict-qualified pointer has a special association
>> with that pointer. This association, defined in 6.7.3.1 below, require s that all accesses to
>> that object use, directly or indirectly, the value of that particular pointer.
Désolé, je ne vois aucune contradiction.
Antoine
Non. C'est tout l'enjeu de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
Désolé, je ne vois aucune contradiction.
Taurre écrivit :
>> En fait je le vois comme une partition de l'espace des objets en n+1
>> ensembles, où n est le nombre de pointeurs restreints. Dans la derni ère
>> partie, les objets peuvent être atteints par différents pointeurs
>> (alias), mais ne peuvent être atteints par l'un quelconque des n
>> pointeurs restreints ou une de leurs dérivations.
> C'est aussi l'image que j'ai en tête, mais le problème c'est que le s
> exemples donné par la Norme ne semble pas tout à fait la suivre. En
> effet, si je reprends mon exemple du début où seul le pointeur "v" est
> qualifié de restreint, dans ce cas on se retrouve avec deux
> partitions: une pour les objets accédés par "v" et une pour les aut res
> (si j'ai bien saisit?).
Oui.
> En suivant cette logique, on pourrait donc
> supposer que l'optimisation aura lieu,
Non. C'est tout l'onjet de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
> cependant elle ne se produira que si tous les pointeurs sont
> qualifiés de restreint...
Euh, là c'est ton analyse du comportement de GCC. GCC est un gros
programme, je n'ai pas les possibilités intellectuelles pour détermin er
son comportement (qui par ailleurs varie avec les versions).
> La même
> analyse peut être appliquée au prototype des fonctions standard:
> pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
> restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
> Je trouve la définition de la Norme franchement floue,
Disons que le style de cette partie tranche assez nettement avec le
reste ; c'est dû en partie au fait que les rédacteurs ne sont pas les mêmes.
> c'est limite si elle ne se contredit pas dans son exemple numero deux
> (6.7.3.1 § 8 p 111) quand elle dit:
>> EXAMPLE 2 The function parameter declarations in the following example
> void f(int n, int * restrict p, int * restrict q)
<snip>
>> assert that, during each execution of the function, if an object is ac cessed through
>> one of the pointer parameters, then it is not also accessed through th e other.
> alors qu'elle dit plus haut (6.7.3 § 7 p 109):
>> An object that is accessed through a restrict-qualified pointer has a special association
>> with that pointer. This association, defined in 6.7.3.1 below, require s that all accesses to
>> that object use, directly or indirectly, the value of that particular pointer.
Désolé, je ne vois aucune contradiction.
Antoine
Non. C'est tout l'enjeu de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
Désolé, je ne vois aucune contradiction.
Taurre écrivit :
>> En fait je le vois comme une partition de l'espace des objets en n+1
>> ensembles, où n est le nombre de pointeurs restreints. Dans la derni ère
>> partie, les objets peuvent être atteints par différents pointeurs
>> (alias), mais ne peuvent être atteints par l'un quelconque des n
>> pointeurs restreints ou une de leurs dérivations.
> C'est aussi l'image que j'ai en tête, mais le problème c'est que le s
> exemples donné par la Norme ne semble pas tout à fait la suivre. En
> effet, si je reprends mon exemple du début où seul le pointeur "v" est
> qualifié de restreint, dans ce cas on se retrouve avec deux
> partitions: une pour les objets accédés par "v" et une pour les aut res
> (si j'ai bien saisit?).
Oui.
> En suivant cette logique, on pourrait donc
> supposer que l'optimisation aura lieu,
Non. C'est tout l'onjet de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
> cependant elle ne se produira que si tous les pointeurs sont
> qualifiés de restreint...
Euh, là c'est ton analyse du comportement de GCC. GCC est un gros
programme, je n'ai pas les possibilités intellectuelles pour détermin er
son comportement (qui par ailleurs varie avec les versions).
> La même
> analyse peut être appliquée au prototype des fonctions standard:
> pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
> restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
> Je trouve la définition de la Norme franchement floue,
Disons que le style de cette partie tranche assez nettement avec le
reste ; c'est dû en partie au fait que les rédacteurs ne sont pas les mêmes.
> c'est limite si elle ne se contredit pas dans son exemple numero deux
> (6.7.3.1 § 8 p 111) quand elle dit:
>> EXAMPLE 2 The function parameter declarations in the following example
> void f(int n, int * restrict p, int * restrict q)
<snip>
>> assert that, during each execution of the function, if an object is ac cessed through
>> one of the pointer parameters, then it is not also accessed through th e other.
> alors qu'elle dit plus haut (6.7.3 § 7 p 109):
>> An object that is accessed through a restrict-qualified pointer has a special association
>> with that pointer. This association, defined in 6.7.3.1 below, require s that all accesses to
>> that object use, directly or indirectly, the value of that particular pointer.
Désolé, je ne vois aucune contradiction.
Antoine
Non. C'est tout l'enjeu de mon premier message : le fait est que l'on
ait une opportunité d'optimisation ne signifie pas obligatoirement que
le compilateur va effectivement réaliser la dite optimisation.
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'au tre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
De plus, la norme est une sorte d'exemple à suivre dans la manière de
déclarer les interfaces, et là aussi il est plus logique et plus clai r
de déclarer tous les pointeurs comme restreints.
Par ailleurs, je soupçonne que le fait de déclarer des paramètres c omme
restreint doive permettre à des analyseurs de détecter des cas de
confusion de variables, ou au moins de soulever des questions sur des
constructions litigieuses, qui auraient avantage à être réécrites de
manière plus claire.
Désolé, je ne vois aucune contradiction.
On 4 mai, 13:56, Antoine Leca wrote:Taurre écrivit :La même
analyse peut être appliquée au prototype des fonctions standard:
pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'autre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
Sinon, par curiosité, quelles opportunités d'optimisation pourraient-
être perdues? Auriez-vous un exemple?
On 4 mai, 13:56, Antoine Leca wrote:
Taurre écrivit :
La même
analyse peut être appliquée au prototype des fonctions standard:
pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'autre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
Sinon, par curiosité, quelles opportunités d'optimisation pourraient-
être perdues? Auriez-vous un exemple?
On 4 mai, 13:56, Antoine Leca wrote:Taurre écrivit :La même
analyse peut être appliquée au prototype des fonctions standard:
pourquoi qualifié les deux pointeurs utilisé par la fonction memcpy de
restreint alors que logiquement un seul suffit?
Parce que l'implémentation des fonctions de la bibliothèque standard
peut utiliser à sa guise d'autres objets (qui seront donc dans la
dernière partie). Si un seul des deux pointeurs était restreint, l'autre
serait dans la dernière partie aussi, et cela empêcherait des
opportunités d'optimisation ; la norme ne peut pas arbitrairement faire
ce genre de choses, surtout quand il est si simple de faire bien.
Sinon, par curiosité, quelles opportunités d'optimisation pourraient-
être perdues? Auriez-vous un exemple?
Taurre écrivit :
> On 4 mai, 13:56, Antoine Leca wrote:
>> Taurre écrivit :
>>> La même
>>> analyse peut être appliquée au prototype des fonctions standard:
>>> pourquoi qualifié les deux pointeurs utilisé par la fonction memc py de
>>> restreint alors que logiquement un seul suffit?
>> Parce que l'implémentation des fonctions de la bibliothèque standa rd
>> peut utiliser à sa guise d'autres objets (qui seront donc dans la
>> dernière partie). Si un seul des deux pointeurs était restreint, l 'autre
>> serait dans la dernière partie aussi, et cela empêcherait des
>> opportunités d'optimisation ; la norme ne peut pas arbitrairement fa ire
>> ce genre de choses, surtout quand il est si simple de faire bien.
> Sinon, par curiosité, quelles opportunités d'optimisation pourraien t-
> être perdues? Auriez-vous un exemple?
Avec memcpy ? Mmmm... environnement multi-ALU, avec des coprocesseurs
(genre DMA ou blitter) capables de faire des copies de zones mémoires
indépendament ; si la source et la destination sont restreintes, le
compilateur peut supposer que le code environnant n'agira pas dessus, y
compris par effet de bord des autres coprocesseurs, et donc lancer la
copie sur le coprocesseur sans primitive de synchronisation. Sans la
condition de restriction, les primitives de synchronisation peuvent
devenir nécessaire, et on perd donc une occasion d'optimisation.
Et si tu trouves que c'est tiré par les cheveux, on peut être d'accor d.
Mais je pense qu'en fixant quelques axiomes, on doit pouvoir arriver à
des conditions réalistes qui peuvent justifier la suppression d'une
optimisation du fait de la suppression d'un qualificatif restrict dans
une déclaration de la bibliothèque standard.
Antoine
Taurre écrivit :
> On 4 mai, 13:56, Antoine Leca wrote:
>> Taurre écrivit :
>>> La même
>>> analyse peut être appliquée au prototype des fonctions standard:
>>> pourquoi qualifié les deux pointeurs utilisé par la fonction memc py de
>>> restreint alors que logiquement un seul suffit?
>> Parce que l'implémentation des fonctions de la bibliothèque standa rd
>> peut utiliser à sa guise d'autres objets (qui seront donc dans la
>> dernière partie). Si un seul des deux pointeurs était restreint, l 'autre
>> serait dans la dernière partie aussi, et cela empêcherait des
>> opportunités d'optimisation ; la norme ne peut pas arbitrairement fa ire
>> ce genre de choses, surtout quand il est si simple de faire bien.
> Sinon, par curiosité, quelles opportunités d'optimisation pourraien t-
> être perdues? Auriez-vous un exemple?
Avec memcpy ? Mmmm... environnement multi-ALU, avec des coprocesseurs
(genre DMA ou blitter) capables de faire des copies de zones mémoires
indépendament ; si la source et la destination sont restreintes, le
compilateur peut supposer que le code environnant n'agira pas dessus, y
compris par effet de bord des autres coprocesseurs, et donc lancer la
copie sur le coprocesseur sans primitive de synchronisation. Sans la
condition de restriction, les primitives de synchronisation peuvent
devenir nécessaire, et on perd donc une occasion d'optimisation.
Et si tu trouves que c'est tiré par les cheveux, on peut être d'accor d.
Mais je pense qu'en fixant quelques axiomes, on doit pouvoir arriver à
des conditions réalistes qui peuvent justifier la suppression d'une
optimisation du fait de la suppression d'un qualificatif restrict dans
une déclaration de la bibliothèque standard.
Antoine
Taurre écrivit :
> On 4 mai, 13:56, Antoine Leca wrote:
>> Taurre écrivit :
>>> La même
>>> analyse peut être appliquée au prototype des fonctions standard:
>>> pourquoi qualifié les deux pointeurs utilisé par la fonction memc py de
>>> restreint alors que logiquement un seul suffit?
>> Parce que l'implémentation des fonctions de la bibliothèque standa rd
>> peut utiliser à sa guise d'autres objets (qui seront donc dans la
>> dernière partie). Si un seul des deux pointeurs était restreint, l 'autre
>> serait dans la dernière partie aussi, et cela empêcherait des
>> opportunités d'optimisation ; la norme ne peut pas arbitrairement fa ire
>> ce genre de choses, surtout quand il est si simple de faire bien.
> Sinon, par curiosité, quelles opportunités d'optimisation pourraien t-
> être perdues? Auriez-vous un exemple?
Avec memcpy ? Mmmm... environnement multi-ALU, avec des coprocesseurs
(genre DMA ou blitter) capables de faire des copies de zones mémoires
indépendament ; si la source et la destination sont restreintes, le
compilateur peut supposer que le code environnant n'agira pas dessus, y
compris par effet de bord des autres coprocesseurs, et donc lancer la
copie sur le coprocesseur sans primitive de synchronisation. Sans la
condition de restriction, les primitives de synchronisation peuvent
devenir nécessaire, et on perd donc une occasion d'optimisation.
Et si tu trouves que c'est tiré par les cheveux, on peut être d'accor d.
Mais je pense qu'en fixant quelques axiomes, on doit pouvoir arriver à
des conditions réalistes qui peuvent justifier la suppression d'une
optimisation du fait de la suppression d'un qualificatif restrict dans
une déclaration de la bibliothèque standard.
Antoine
During each execution of B, let L be any lvalue that has &L based on P. I f L is used to
access the value of the object X that it designates, AND X IS ALSO MODIFI ED (by any means),
then the following requirements apply: [...]
During each execution of B, let L be any lvalue that has &L based on P. I f L is used to
access the value of the object X that it designates, AND X IS ALSO MODIFI ED (by any means),
then the following requirements apply: [...]
During each execution of B, let L be any lvalue that has &L based on P. I f L is used to
access the value of the object X that it designates, AND X IS ALSO MODIFI ED (by any means),
then the following requirements apply: [...]
Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Taurre wrote:
> Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Tu devrais installer soit le compilateur d'Intel soit celui d'Oracle.
Les 2 parviennent à optimiser dès que soit a soit c est restrict (b e n
revanche ne suffit pas).
Lors des messages initiaux de cette discussion, il m'etait vaguement reven u
en memoire que, effectivement, restrict ne sert a rien.
Taurre wrote:
> Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Tu devrais installer soit le compilateur d'Intel soit celui d'Oracle.
Les 2 parviennent à optimiser dès que soit a soit c est restrict (b e n
revanche ne suffit pas).
Lors des messages initiaux de cette discussion, il m'etait vaguement reven u
en memoire que, effectivement, restrict ne sert a rien.
Taurre wrote:
> Cela explique pourquoi un tel exemple ne peut pas être optimisé:
Tu devrais installer soit le compilateur d'Intel soit celui d'Oracle.
Les 2 parviennent à optimiser dès que soit a soit c est restrict (b e n
revanche ne suffit pas).
Lors des messages initiaux de cette discussion, il m'etait vaguement reven u
en memoire que, effectivement, restrict ne sert a rien.
n'est ce pas un peu excessif d'optimiser lorsque "a" ou "b" (si son
affectation est la première) sont des pointeurs restreints? La Norme
permet d'accéder à un objet pointé par un pointeur restreint si
l'accès via un autre pointeur ne vise pas à le modifier, cela me
semble un peu risqué non?
n'est ce pas un peu excessif d'optimiser lorsque "a" ou "b" (si son
affectation est la première) sont des pointeurs restreints? La Norme
permet d'accéder à un objet pointé par un pointeur restreint si
l'accès via un autre pointeur ne vise pas à le modifier, cela me
semble un peu risqué non?
n'est ce pas un peu excessif d'optimiser lorsque "a" ou "b" (si son
affectation est la première) sont des pointeurs restreints? La Norme
permet d'accéder à un objet pointé par un pointeur restreint si
l'accès via un autre pointeur ne vise pas à le modifier, cela me
semble un peu risqué non?