Pour donner un exemple plus concret :

int f(int n)
{
return n/4;
}

Pour cette fonction le compilateur me génère le code assembleur suivant :

mov eax,dword ptr [ebp+8]
cdq
and edx,3
add eax,edx
sar eax,2

Alors que si je change le "int n" en "unsigned int n", j'obtiens le code assembleur suivant :

mov eax,dword ptr [ebp+8]
shr eax,2

Avec unsigned le compilateur se contente d'un simple décalage.

en effet compile en -O3 avec icc 14, je n'obtiens pas le meme code non plus. En signed:

movl %edi, %eax #3.10
sarl $1, %eax #3.10
shrl $30, %eax #3.10
addl %edi, %eax #3.10
sarl $2, %eax #3.10
ret #3.10

en unsigned:

shrl $2, %edi #3.10
movl %edi, %eax #3.10
ret #3.10

Tellement longtemps que je n'ai pas vu Chris_27 sur le forum, cela fait plaisir de voir qu'il est toujours autant en forme :D

PocoIo : Ok, mais dans ce cas l'opération n'est pas la même si n est signed ou unsigned (la faute à la sémantique du C ). Si n est unsigned, n/4 fait la division euclidienne de n par 4. Mais si c'est un signed, l'opération n'est plus une division euclidienne (le quotient est arrondi vers 0, alors qu'il est arrondi vers le bas dans une division euclidienne).

En tout cas :
1. Le shift arithmétique correspond parfaitement à la division euclidienne sur des entiers signés.
2. Dans un contexte plus gros (ou après inlining), le compilo va redécouvrir tout seul qu'on pouvait s'en sortir avec une division euclidienne et donc réduire l'assembleur correspondant à un appel à sar.
3. Changer le signe de n dans ton exemple va changer la sémantique du code, donc possiblement introduire des bugs.

Moralement, je pense qu'un shift arithmetique devrait suffir. Alors pourquoi le compilateur ajoute d'autres instructions?

Parce que la sémantique du C pue, essentiellement. Enfin, c'est pas nouveau. Quelqu'un a déjà soulevé à juste titre le fait que l'encodage (complément à 1 ou à 2) des négatifs n'était pas imposé dans les standards du langage.

En math (où le reste d'une division est toujours positif), -11/3 ça fait -4 et il reste +1.

En circuiterie/assembleur, on fait comme en math (le complément à 2 a été choisi pour coller à l'arithmétique modulaire, après tout).

En C, -11/3 ça fait -3 et il reste -2. FAIL.

" En circuiterie/assembleur, on fait comme en math "

Pourtant l'instruction idiv arrondi aussi vers 0, comme en C.

idiv n'est pas une instruction réelle, c'est du microcode qui prend des dizaines de cycles à s'exécuter.

Cela-dit il me semblait que, de façon générale en informatique (et pas que en C), pour la division entière on cherche à arrondir vers 0 notamment pour éviter que la valeur absolue du quotient soit différente et que par exemple :

-(11/3) soit différent de (-11)/3

Je cite mon ancienne prof de bio : "N'utilise pas les mots [car] et [parce que], ils ne permettent pas de faire un raisonnement scientifique valide".

elite: 1+2 ne me permet pas de ccnclure quoi que ce soit, vu qye idiv n'est pas une vraie instruction. Mais tu aurais pu convaincre en tournant ta phrase autrement et en utilisant un "donc". Essaie, tu verras que ça marche beaucoup mieux.

Sinon, je parlais d'optims de type propagation de constantes au sein d'une fonction. Après, j'avoue que vu le code en question (dont la taille n'a fait que chuter depuis que je suis dessus), je n'ai pas eu le courage de chercher précisément pourquoi gcc arrivait à optimiser ça de façon aussi flagrante.

mmm, tout ca, ce sont des utilisations de const qui (moralement) remplace un #define ou un parametre template.

Mais l'utilisation principale des const en C++ n'est pas la. C'est typiquement de passer un pointeur vers une donne constant (ou un reference mais en l'occurence ca ne change rien). Et la ce n'est pas que la donnee est constante au sein de tout le programme, ca veut juste dire que la fonction courrante ne peut pas le changer. Et ca, je ne pense par que ca ammene une optimisation quelconque. Does it?

"1+2 ne me permet pas de ccnclure quoi que ce soit, vu qye idiv n'est pas une vraie instruction"

je comprends pas, tu veux dire quoi par la ?

Que la seule conclusion logique après lecture de ton explication est qu'on se fout des shift vu qu'il suffit de faire un idiv.

Et j'espère qu'on est d'accord pour dire que c'est tout sauf la bonne conclusion à tirer.

on est d'accord. je voulais seulement dire qu'on peut pas remplacer idiv par un simple sift a cause de l’arrondi vers 0. exemple avec /2

1. define div2(val) (val >> 1)
2. define idiv2(val) ((val+1) >> 1)

assert( div2(-13) == -13/2 ) // erreur
assert( idiv2(-13) == -13/2 ) // ok

apres va savoir pourquoi idiv arrondi vers 0 (c'est la même chose avec ARM)

" apres va savoir pourquoi idiv arrondi vers 0 (c'est la même chose avec ARM) "

Je pense que c'est pour la raison que j'ai énoncé plus haut, à savoir pour éviter que :

" -(11/3) soit différent de (-11)/3 "