编译器可以考虑的一个小小可能性

Question

这段c代码

2. int test_int_mod()
3. {
4.   unsigned int mode_u;
5.   int mode_i;
6.   
7.   int x;
8.   unsigned int y;
10.   x=99;
11.   y=77;
13.   x=(x+1)%64;
14.   y=(y+1)%64;
15.   
16.   x=(x+1)%32;
17.   y=(y+1)%32;
19.   mode_u=32;
20.   mode_i=32;
21.   x=(x+1)%mode_i;
22.   y=(y+1)%mode_u;
24.   mode_u=11;
25.   mode_i=12;
26.   x=(x+1)%mode_i;
27.   y=(y+1)%mode_u;
28.   
29.   return(x);
30. }

复制代码

在VC6.0下被编译成了如下:

2. ?test_int_mod@@YAHXZ PROC NEAR                                ; test_int_mod
3.         push        ebp
4.         mov        ebp, esp
5.         sub        esp, 16                                        ; 00000010H
6.         mov        DWORD PTR _x$[ebp], 99                        ; 00000063H
7.         mov        DWORD PTR _y$[ebp], 77                        ; 0000004dH
8.         mov        eax, DWORD PTR _x$[ebp]
9.         add        eax, 1
10.         and        eax, -2147483585                        ; 8000003fH
11.         jns        SHORT $L69607
12.         dec        eax
13.         or        eax, -64                                ; ffffffc0H
14.         inc        eax
15.         mov        DWORD PTR _x$[ebp], eax
16.         mov        eax, DWORD PTR _y$[ebp]
17.         add        eax, 1
18.         xor        edx, edx
19.         mov        ecx, 64                                        ; 00000040H
20.         div        ecx
21.         mov        DWORD PTR _y$[ebp], edx
22.         mov        edx, DWORD PTR _x$[ebp]
23.         add        edx, 1
24.         and        edx, -2147483617                        ; 8000001fH
25.         jns        SHORT $L69608
26.         dec        edx
27.         or        edx, -32                                ; ffffffe0H
28.         inc        edx
29.         mov        DWORD PTR _x$[ebp], edx
30.         mov        eax, DWORD PTR _y$[ebp]
31.         add        eax, 1
32.         xor        edx, edx
33.         mov        ecx, 32                                        ; 00000020H
34.         div        ecx
35.         mov        DWORD PTR _y$[ebp], edx
36.         mov        DWORD PTR _mode_u$[ebp], 32                ; 00000020H
37.         mov        DWORD PTR _mode_i$[ebp], 32                ; 00000020H
38.         mov        eax, DWORD PTR _x$[ebp]
39.         add        eax, 1
40.         cdq
41.         idiv        DWORD PTR _mode_i$[ebp]
42.         mov        DWORD PTR _x$[ebp], edx
43.         mov        eax, DWORD PTR _y$[ebp]
44.         add        eax, 1
45.         xor        edx, edx
46.         div        DWORD PTR _mode_u$[ebp]
47.         mov        DWORD PTR _y$[ebp], edx
48.         mov        DWORD PTR _mode_u$[ebp], 11                ; 0000000bH
49.         mov        DWORD PTR _mode_i$[ebp], 12                ; 0000000cH
50.         mov        eax, DWORD PTR _x$[ebp]
51.         add        eax, 1
52.         cdq
53.         idiv        DWORD PTR _mode_i$[ebp]
54.         mov        DWORD PTR _x$[ebp], edx
55.         mov        eax, DWORD PTR _y$[ebp]
56.         add        eax, 1
57.         xor        edx, edx
58.         div        DWORD PTR _mode_u$[ebp]
59.         mov        DWORD PTR _y$[ebp], edx
60.         mov        eax, DWORD PTR _x$[ebp]
61.         mov        esp, ebp
62.         pop        ebp
63.         ret        0
64. ?test_int_mod@@YAHXZ ENDP                                ; test_int_mod

复制代码

其中不能针对mode_u变量的值做优化(gcc也类似问题),但对大家自己的特定编译器或虚拟机解释器在编译时则可考虑加入判断mode_u是不是2的次幂来做不同的处理的代码.
但对于边解释边运行的机制来说:这样一来判断能力mode_u是不是2的次幂 又要多出代码耗时了.
因此只能考虑编译型或伪编译性执行采用这样的建议.

Answer 1

不用细看，基于数值特征的优化基本上是费力不讨好。把这些交给程序员在他们真正需要优化的地方自己去解决更好。比如用移位和位逻辑运算代替乘除和求余。

下面这样的代码你认为应该被优化掉吗
int i, t1, t2;
i = 0;
t1 = i  *  3;
t2 = t1 * 4;

Answer 2

你认为以下代码：

2. #include <stdio.h>
3. int main()
4. {
5.       int i,j;
6.       for(i=0,j=0;i<10000;i++)
7.              j+=i;
8.       return 0;
9. }

复制代码
应该被优化为以下吗？

2. .globl main
3. main:
4.         xorl    %eax, %eax
5.         ret

复制代码

Answer 3

2,3楼的观点是正确的!

我表述的有问题.
意思不是优化掉代码,而是根据输入值分支到相对合适的模块.

[ 本帖最后由 system888net 于 2008-5-6 23:57 编辑 ]

Answer 4

原帖由 Wind-Son 于 2008-5-6 22:31 发表
不用细看，基于数值特征的优化基本上是费力不讨好。把这些交给程序员在他们真正需要优化的地方自己去解决更好。比如用移位和位逻辑运算代替乘除和求余。

下面这样的代码你认为应该被优化掉吗
int i, t1, t2 ...

可以优化为:
nt i, t1, t2;
i = 0;  // or  i=input();

if(i==0)
{
  t1=0;
  t2=0;
}
else
{
   t1 = i  *  3;
   t2 = t1 * 4;
}
对于虚拟机是有意义的

Answer 5

我倒，为了一个乘法，居然加了个条件分支.........
有这么做的编译器？除了bt,我想不出来别的词语形容。
你说直接优化为
int i=0,t1=0,t2=0;
我还信。

Answer 6

另外，X86上对于这种乘特殊数（一般比较小的数），可能会采取用寻址来实现乘法。
比如：
leal    (%eax,%eax,2), %eax
其实就是为了实现乘3
当然，这种类型优化体系结构相关

Answer 7

原帖由 cjaizss 于 2008-5-7 00:37 发表
我倒，为了一个乘法，居然加了个条件分支.........
有这么做的编译器？除了bt,我想不出来别的词语形容。
你说直接优化为
int i=0,t1=0,t2=0;
我还信。

nt i, t1, t2;
i = 0;  // or  i=input();

if(i==0)  //对于用户i=input(); 多次输入的时候,i=0的特例虚拟机的确可以快速出结果.
{
  t1=0;
  t2=0;
}
else
{
   //假如这里有多次的运算..., 对于i=0用户的感觉虚拟机太苯了
   t1 = i  *  3;
   t2 = t1 * 4;
}

Answer 8

原帖由 cjaizss 于 2008-5-7 00:47 发表
另外，X86上对于这种乘特殊数（一般比较小的数），可能会采取用寻址来实现乘法。
比如：
leal    (%eax,%eax,2), %eax
其实就是为了实现乘3
当然，这种类型优化体系结构相关

这个观点同意

Answer 9

原帖由 system888net 于 2008-5-7 00:48 发表

nt i, t1, t2;
i = 0;  // or  i=input();

if(i==0)  //对于用户i=input(); 多次输入的时候,i=0的特例虚拟机的确可以快速出结果.
{
  t1=0;
  t2=0;
}
else
{
   //假如这里有多次的运算... ...