void
test (int *a, int *b, int * restrict v)
{
*a = *v;
*b = *v;
}
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière. Donc, en
toute logique, on peut supposer que l'objet pointé par la variable "v"
ne sera pas modifié lors de l'exécution de cette fonction. Or, si je
compile ce code, j'obtiens ces lignes en assembleur pour la fonction
"test":
movl (%rdx), %eax
movl %eax, (%rdi)
movl (%rdx), %eax
movl %eax, (%rsi)
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois... l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
void
test (int *a, int *b, int * restrict v)
{
*a = *v;
*b = *v;
}
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière. Donc, en
toute logique, on peut supposer que l'objet pointé par la variable "v"
ne sera pas modifié lors de l'exécution de cette fonction. Or, si je
compile ce code, j'obtiens ces lignes en assembleur pour la fonction
"test":
movl (%rdx), %eax
movl %eax, (%rdi)
movl (%rdx), %eax
movl %eax, (%rsi)
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois... l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
void
test (int *a, int *b, int * restrict v)
{
*a = *v;
*b = *v;
}
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière. Donc, en
toute logique, on peut supposer que l'objet pointé par la variable "v"
ne sera pas modifié lors de l'exécution de cette fonction. Or, si je
compile ce code, j'obtiens ces lignes en assembleur pour la fonction
"test":
movl (%rdx), %eax
movl %eax, (%rdi)
movl (%rdx), %eax
movl %eax, (%rsi)
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois... l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
Taurre wrote:
> void
> test (int *a, int *b, int * restrict v)
> {
> *a = *v;
> *b = *v;
> }
[...]
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière. Donc, e n
> toute logique, on peut supposer que l'objet pointé par la variable "v "
> ne sera pas modifié lors de l'exécution de cette fonction. Or, si j e
> compile ce code, j'obtiens ces lignes en assembleur pour la fonction
> "test":
> movl (%rdx), %eax
> movl %eax, (%rdi)
> movl (%rdx), %eax
> movl %eax, (%rsi)
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois... l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
(sur une archi où les int sont forcément alignés, ça ne serait pa s
absurde de faire l'optimisation sans restrict j'ai l'impression, mais
je peux rater quelque chose)
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Essaie un gcc plus récent alors.
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Essaie un gcc plus récent alors.
Taurre wrote:
> void
> test (int *a, int *b, int * restrict v)
> {
> *a = *v;
> *b = *v;
> }
[...]
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière. Donc, e n
> toute logique, on peut supposer que l'objet pointé par la variable "v "
> ne sera pas modifié lors de l'exécution de cette fonction. Or, si j e
> compile ce code, j'obtiens ces lignes en assembleur pour la fonction
> "test":
> movl (%rdx), %eax
> movl %eax, (%rdi)
> movl (%rdx), %eax
> movl %eax, (%rsi)
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois... l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
(sur une archi où les int sont forcément alignés, ça ne serait pa s
absurde de faire l'optimisation sans restrict j'ai l'impression, mais
je peux rater quelque chose)
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Essaie un gcc plus récent alors.
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Essaie un gcc plus récent alors.
Taurre wrote:
> void
> test (int *a, int *b, int * restrict v)
> {
> *a = *v;
> *b = *v;
> }
[...]
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière. Donc, e n
> toute logique, on peut supposer que l'objet pointé par la variable "v "
> ne sera pas modifié lors de l'exécution de cette fonction. Or, si j e
> compile ce code, j'obtiens ces lignes en assembleur pour la fonction
> "test":
> movl (%rdx), %eax
> movl %eax, (%rdi)
> movl (%rdx), %eax
> movl %eax, (%rsi)
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois... l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
(sur une archi où les int sont forcément alignés, ça ne serait pa s
absurde de faire l'optimisation sans restrict j'ai l'impression, mais
je peux rater quelque chose)
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Essaie un gcc plus récent alors.
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Essaie un gcc plus récent alors.
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Oui, mais n'est ce pas un comportement interdit? Normalement, en
qualifiant le pointeur "v" de restreint, on indique au compilateur que
l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, les
pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fait,
mais une partie de l'objet pointé par "v" est accéder via "a" ce qui
constitue un comportement indéterminé il me semble).
Essaie un gcc plus récent alors.
C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
la plus récente (4-4), je vais essayer avec une autre, merci du
conseil ;)
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Oui, mais n'est ce pas un comportement interdit? Normalement, en
qualifiant le pointeur "v" de restreint, on indique au compilateur que
l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, les
pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fait,
mais une partie de l'objet pointé par "v" est accéder via "a" ce qui
constitue un comportement indéterminé il me semble).
Essaie un gcc plus récent alors.
C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
la plus récente (4-4), je vais essayer avec une autre, merci du
conseil ;)
En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
compilateur.
char c[42];
test(c,b,c+1);
--> l'écriture dans *a modifie la valeur *v.
Oui, mais n'est ce pas un comportement interdit? Normalement, en
qualifiant le pointeur "v" de restreint, on indique au compilateur que
l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, les
pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fait,
mais une partie de l'objet pointé par "v" est accéder via "a" ce qui
constitue un comportement indéterminé il me semble).
Essaie un gcc plus récent alors.
C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
la plus récente (4-4), je vais essayer avec une autre, merci du
conseil ;)
Taurre wrote:
>> En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
>> compilateur.
>> char c[42];
>> test(c,b,c+1);
>> --> l'écriture dans *a modifie la valeur *v.
> Oui, mais n'est ce pas un comportement interdit? Normalement, en
> qualifiant le pointeur "v" de restreint, on indique au compilateur que
> l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
> pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, l es
> pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fai t,
> mais une partie de l'objet pointé par "v" est accéder via "a" ce qu i
> constitue un comportement indéterminé il me semble).
C'est aussi comme ça que j'avais compris restrict au début, mais
ensuite j'ai regardé ce que faisait gcc, et les exemples donnés par l e
standard, et ça ne collait pas bien.
exemple 1:
int * restrict a;
int * restrict b;
extern int c[];
exemple 2:
void f(int n, int * restrict p, int * restrict q)
{
while (n-- > 0)
*p++ = *q++;
}
autre exemple:
void *memcpy(void *restrict s1, const void *restrict s2, size_t n);
À chaque fois (sauf pour la variable extern) restrict est mis en
double. Le texte n'a pas changé dans C1X, c'est toujours aussi peu
clair.
Il est possible aussi que gcc soit trop conservateur.
>> Essaie un gcc plus récent alors.
> C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
> la plus récente (4-4), je vais essayer avec une autre, merci du
> conseil ;)
Je vais tuer le suspens, mais j'avais essayé avant de poster, et ça
fait la même optimisation que pour int.
Taurre wrote:
>> En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
>> compilateur.
>> char c[42];
>> test(c,b,c+1);
>> --> l'écriture dans *a modifie la valeur *v.
> Oui, mais n'est ce pas un comportement interdit? Normalement, en
> qualifiant le pointeur "v" de restreint, on indique au compilateur que
> l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
> pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, l es
> pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fai t,
> mais une partie de l'objet pointé par "v" est accéder via "a" ce qu i
> constitue un comportement indéterminé il me semble).
C'est aussi comme ça que j'avais compris restrict au début, mais
ensuite j'ai regardé ce que faisait gcc, et les exemples donnés par l e
standard, et ça ne collait pas bien.
exemple 1:
int * restrict a;
int * restrict b;
extern int c[];
exemple 2:
void f(int n, int * restrict p, int * restrict q)
{
while (n-- > 0)
*p++ = *q++;
}
autre exemple:
void *memcpy(void *restrict s1, const void *restrict s2, size_t n);
À chaque fois (sauf pour la variable extern) restrict est mis en
double. Le texte n'a pas changé dans C1X, c'est toujours aussi peu
clair.
Il est possible aussi que gcc soit trop conservateur.
>> Essaie un gcc plus récent alors.
> C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
> la plus récente (4-4), je vais essayer avec une autre, merci du
> conseil ;)
Je vais tuer le suspens, mais j'avais essayé avant de poster, et ça
fait la même optimisation que pour int.
Taurre wrote:
>> En fait ce sont "a" et "v" dont tu veux indiquer l'indépendance au
>> compilateur.
>> char c[42];
>> test(c,b,c+1);
>> --> l'écriture dans *a modifie la valeur *v.
> Oui, mais n'est ce pas un comportement interdit? Normalement, en
> qualifiant le pointeur "v" de restreint, on indique au compilateur que
> l'objet sur lequel il pointe ne sera accéder que via lui-même ou un
> pointeur dérivé de lui. Or, dans cet exemple ce n'est pas le cas, l es
> pointeurs "a" et "v" accèdent au même objet (enfin pas tout à fai t,
> mais une partie de l'objet pointé par "v" est accéder via "a" ce qu i
> constitue un comportement indéterminé il me semble).
C'est aussi comme ça que j'avais compris restrict au début, mais
ensuite j'ai regardé ce que faisait gcc, et les exemples donnés par l e
standard, et ça ne collait pas bien.
exemple 1:
int * restrict a;
int * restrict b;
extern int c[];
exemple 2:
void f(int n, int * restrict p, int * restrict q)
{
while (n-- > 0)
*p++ = *q++;
}
autre exemple:
void *memcpy(void *restrict s1, const void *restrict s2, size_t n);
À chaque fois (sauf pour la variable extern) restrict est mis en
double. Le texte n'a pas changé dans C1X, c'est toujours aussi peu
clair.
Il est possible aussi que gcc soit trop conservateur.
>> Essaie un gcc plus récent alors.
> C'est vrai que je suis sous Debian Squeeze et que ma version n'est pas
> la plus récente (4-4), je vais essayer avec une autre, merci du
> conseil ;)
Je vais tuer le suspens, mais j'avais essayé avant de poster, et ça
fait la même optimisation que pour int.
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière.
Donc, en toute logique, on peut supposer que l'objet pointé par la
variable "v" ne sera pas modifié lors de l'exécution de cette fonction.
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois...
l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière.
Donc, en toute logique, on peut supposer que l'objet pointé par la
variable "v" ne sera pas modifié lors de l'exécution de cette fonction.
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois...
l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
si j'ai bien saisit la notion de pointeur restreint cela signifie,
dans le cas de la fonction "test", que l'objet sur lequel pointe la
variable "v" ne peut-être accéder que via cette dernière.
Donc, en toute logique, on peut supposer que l'objet pointé par la
variable "v" ne sera pas modifié lors de l'exécution de cette fonction.
la valeur de l'objet pointé par la variable "v" est chargé deux fois
dans le registre eax alors qu'elle ne devrait l'être qu'une seule
fois...
l'optimisation n'aura lieu que si un ou les deux autres
pointeurs sont également déclaré avec le qualificatif "restrict".
Quelqu'un pourrait-il m'expliquer pourquoi?
- la deuxième porte sur le même code, mais avec des variables de type
char. Dans cette hypothèse, même si les trois pointeurs sont déclarés
avec le qualificatif "restrict", aucune optimisation n'est effectuée
Taurre écrivit :
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière.
Dans ton exemple, v est à la fois une variable int de valeur 10, et un
pointeur restreint (vers la première.) Je ne suis pas sûr que cela
facilite la compréhension pour nous autres humains.
> Donc, en toute logique, on peut supposer que l'objet pointé par la
> variable "v" ne sera pas modifié lors de l'exécution de cette fonct ion.
Oui, puisque le code ne modifie pas le pointeur, et le propos de
restrict est d'affirmer que d'autres modifications n'ont pas lieu par
ailleurs.
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois...
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
> l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
Il faudrait demander aux développeurs de GCC.
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Là encore, c'est un sujet pour GCC. À mon sens, tu peux avoir le cas
théorique où les pointeurs pointent vers le même mot mémoire (un mot
pouvant être constitué de plusieurs bytes), et GCC veux peut-être éviter
les problèmes liés à des accès concurrents à un même mot.
Cela étant, ce peut être aussi un bête bogue dans le code de GCC...
Dans tous les cas, c'est totalement conforme à la norme, en vertu de ce
qui est rappelé ci-dessus: restrict n'est pas une obligation.
Antoine
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
Il faudrait demander aux développeurs de GCC.
Taurre écrivit :
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière.
Dans ton exemple, v est à la fois une variable int de valeur 10, et un
pointeur restreint (vers la première.) Je ne suis pas sûr que cela
facilite la compréhension pour nous autres humains.
> Donc, en toute logique, on peut supposer que l'objet pointé par la
> variable "v" ne sera pas modifié lors de l'exécution de cette fonct ion.
Oui, puisque le code ne modifie pas le pointeur, et le propos de
restrict est d'affirmer que d'autres modifications n'ont pas lieu par
ailleurs.
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois...
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
> l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
Il faudrait demander aux développeurs de GCC.
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Là encore, c'est un sujet pour GCC. À mon sens, tu peux avoir le cas
théorique où les pointeurs pointent vers le même mot mémoire (un mot
pouvant être constitué de plusieurs bytes), et GCC veux peut-être éviter
les problèmes liés à des accès concurrents à un même mot.
Cela étant, ce peut être aussi un bête bogue dans le code de GCC...
Dans tous les cas, c'est totalement conforme à la norme, en vertu de ce
qui est rappelé ci-dessus: restrict n'est pas une obligation.
Antoine
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
Il faudrait demander aux développeurs de GCC.
Taurre écrivit :
> si j'ai bien saisit la notion de pointeur restreint cela signifie,
> dans le cas de la fonction "test", que l'objet sur lequel pointe la
> variable "v" ne peut-être accéder que via cette dernière.
Dans ton exemple, v est à la fois une variable int de valeur 10, et un
pointeur restreint (vers la première.) Je ne suis pas sûr que cela
facilite la compréhension pour nous autres humains.
> Donc, en toute logique, on peut supposer que l'objet pointé par la
> variable "v" ne sera pas modifié lors de l'exécution de cette fonct ion.
Oui, puisque le code ne modifie pas le pointeur, et le propos de
restrict est d'affirmer que d'autres modifications n'ont pas lieu par
ailleurs.
> la valeur de l'objet pointé par la variable "v" est chargé deux foi s
> dans le registre eax alors qu'elle ne devrait l'être qu'une seule
> fois...
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
> l'optimisation n'aura lieu que si un ou les deux autres
> pointeurs sont également déclaré avec le qualificatif "restrict".
> Quelqu'un pourrait-il m'expliquer pourquoi?
Il faudrait demander aux développeurs de GCC.
> - la deuxième porte sur le même code, mais avec des variables de ty pe
> char. Dans cette hypothèse, même si les trois pointeurs sont décl arés
> avec le qualificatif "restrict", aucune optimisation n'est effectuée
Là encore, c'est un sujet pour GCC. À mon sens, tu peux avoir le cas
théorique où les pointeurs pointent vers le même mot mémoire (un mot
pouvant être constitué de plusieurs bytes), et GCC veux peut-être éviter
les problèmes liés à des accès concurrents à un même mot.
Cela étant, ce peut être aussi un bête bogue dans le code de GCC...
Dans tous les cas, c'est totalement conforme à la norme, en vertu de ce
qui est rappelé ci-dessus: restrict n'est pas une obligation.
Antoine
« devrait » : pas d'accord. La norme est limpide, restrict est une
opportunité d'optimisation, pas une obligation imposée au compilateur .
Il faudrait demander aux développeurs de GCC.
elle suppose donc que n'importe qu'elle lvalue utilisée pour accéder à
l'objet pointé par le pointeur restreint soit dérivé de ce dernier.
Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
pointé par un pointeur non restreint ne doit pas forcément être accédé
via des lvalues dérivées de ce dernier.
Autrement dit, il est possible
qu'un pointeur restreint accède à un objet pointé par un pointeur non
restreint et qu'il y aie donc de l'aliasing.
elle suppose donc que n'importe qu'elle lvalue utilisée pour accéder à
l'objet pointé par le pointeur restreint soit dérivé de ce dernier.
Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
pointé par un pointeur non restreint ne doit pas forcément être accédé
via des lvalues dérivées de ce dernier.
Autrement dit, il est possible
qu'un pointeur restreint accède à un objet pointé par un pointeur non
restreint et qu'il y aie donc de l'aliasing.
elle suppose donc que n'importe qu'elle lvalue utilisée pour accéder à
l'objet pointé par le pointeur restreint soit dérivé de ce dernier.
Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
pointé par un pointeur non restreint ne doit pas forcément être accédé
via des lvalues dérivées de ce dernier.
Autrement dit, il est possible
qu'un pointeur restreint accède à un objet pointé par un pointeur non
restreint et qu'il y aie donc de l'aliasing.
Taurre écrivit :
En supposant (axiome):
> elle suppose donc que n'importe qu'elle lvalue utilisée pour accéde r à
> l'objet pointé par le pointeur restreint soit dérivé de ce dernie r.
On a
> Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
> pointé par un pointeur non restreint ne doit pas forcément être a ccédé
> via des lvalues dérivées de ce dernier.
Mais j'y lis aussi
: cela signifie aussi qu'un objet
: pointé par un pointeur non restreint ne peut pas jamais être accé dé
: via des lvalues dérivées d'un pointeur restreint.
(Les deux ne sont pas incompatibles.)
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.
> Autrement dit, il est possible
> qu'un pointeur restreint accède à un objet pointé par un pointeur non
> restreint et qu'il y aie donc de l'aliasing.
Non. Ce serait une violation de la règle comme quoi les objets pointé s
par les pointeurs restreints ne peuvent être modifiés par ailleurs, e t
cela invaliderait complètement la possibilité d'optimisation. Le
raisonnement est donc incorrect (ce qui peut provenir d'une mauvaise
rédaction de la norme C99).
Antoine
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.
EXAMPLE 2 The function parameter declarations in the following example
assert that, during each execution of the function, if an object is acces sed through
one of the pointer parameters, then it is not also accessed through the o ther.
An object that is accessed through a restrict-qualified pointer has a spe cial association
with that pointer. This association, defined in 6.7.3.1 below, requires t hat all accesses to
that object use, directly or indirectly, the value of that particular poi nter.
Taurre écrivit :
En supposant (axiome):
> elle suppose donc que n'importe qu'elle lvalue utilisée pour accéde r à
> l'objet pointé par le pointeur restreint soit dérivé de ce dernie r.
On a
> Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
> pointé par un pointeur non restreint ne doit pas forcément être a ccédé
> via des lvalues dérivées de ce dernier.
Mais j'y lis aussi
: cela signifie aussi qu'un objet
: pointé par un pointeur non restreint ne peut pas jamais être accé dé
: via des lvalues dérivées d'un pointeur restreint.
(Les deux ne sont pas incompatibles.)
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.
> Autrement dit, il est possible
> qu'un pointeur restreint accède à un objet pointé par un pointeur non
> restreint et qu'il y aie donc de l'aliasing.
Non. Ce serait une violation de la règle comme quoi les objets pointé s
par les pointeurs restreints ne peuvent être modifiés par ailleurs, e t
cela invaliderait complètement la possibilité d'optimisation. Le
raisonnement est donc incorrect (ce qui peut provenir d'une mauvaise
rédaction de la norme C99).
Antoine
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.
EXAMPLE 2 The function parameter declarations in the following example
assert that, during each execution of the function, if an object is acces sed through
one of the pointer parameters, then it is not also accessed through the o ther.
An object that is accessed through a restrict-qualified pointer has a spe cial association
with that pointer. This association, defined in 6.7.3.1 below, requires t hat all accesses to
that object use, directly or indirectly, the value of that particular poi nter.
Taurre écrivit :
En supposant (axiome):
> elle suppose donc que n'importe qu'elle lvalue utilisée pour accéde r à
> l'objet pointé par le pointeur restreint soit dérivé de ce dernie r.
On a
> Oui, mais si on l'a prend a contrario cela signifie aussi qu'un objet
> pointé par un pointeur non restreint ne doit pas forcément être a ccédé
> via des lvalues dérivées de ce dernier.
Mais j'y lis aussi
: cela signifie aussi qu'un objet
: pointé par un pointeur non restreint ne peut pas jamais être accé dé
: via des lvalues dérivées d'un pointeur restreint.
(Les deux ne sont pas incompatibles.)
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.
> Autrement dit, il est possible
> qu'un pointeur restreint accède à un objet pointé par un pointeur non
> restreint et qu'il y aie donc de l'aliasing.
Non. Ce serait une violation de la règle comme quoi les objets pointé s
par les pointeurs restreints ne peuvent être modifiés par ailleurs, e t
cela invaliderait complètement la possibilité d'optimisation. Le
raisonnement est donc incorrect (ce qui peut provenir d'une mauvaise
rédaction de la norme C99).
Antoine
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.
EXAMPLE 2 The function parameter declarations in the following example
assert that, during each execution of the function, if an object is acces sed through
one of the pointer parameters, then it is not also accessed through the o ther.
An object that is accessed through a restrict-qualified pointer has a spe cial association
with that pointer. This association, defined in 6.7.3.1 below, requires t hat all accesses to
that object use, directly or indirectly, the value of that particular poi nter.
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 les
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 autres
(si j'ai bien saisit?).
En suivant cette logique, on pourrait donc
supposer que l'optimisation aura lieu,
cependant elle ne se produira que si tous les pointeurs sont
qualifiés de restreint...
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?
Je trouve la définition de la Norme franchement floue,
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)
assert that, during each execution of the function, if an object is accessed through
one of the pointer parameters, then it is not also accessed through the 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, requires that all accesses to
that object use, directly or indirectly, the value of that particular pointer.
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 les
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 autres
(si j'ai bien saisit?).
En suivant cette logique, on pourrait donc
supposer que l'optimisation aura lieu,
cependant elle ne se produira que si tous les pointeurs sont
qualifiés de restreint...
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?
Je trouve la définition de la Norme franchement floue,
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)
assert that, during each execution of the function, if an object is accessed through
one of the pointer parameters, then it is not also accessed through the 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, requires that all accesses to
that object use, directly or indirectly, the value of that particular pointer.
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 les
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 autres
(si j'ai bien saisit?).
En suivant cette logique, on pourrait donc
supposer que l'optimisation aura lieu,
cependant elle ne se produira que si tous les pointeurs sont
qualifiés de restreint...
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?
Je trouve la définition de la Norme franchement floue,
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)
assert that, during each execution of the function, if an object is accessed through
one of the pointer parameters, then it is not also accessed through the 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, requires that all accesses to
that object use, directly or indirectly, the value of that particular pointer.