[Bug tree-optimization/47004] New: missed optimization in comparison

[bosch at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47004

   Summary: missed optimization in comparison
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bo...@gcc.gnu.org


Created attachment 22811
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22811
Preprocessed source to reproduce

The attached C test case shows missed optimization, where lenzero could be
optimized to generate the same code as lenzero2. This pattern is very common in
Ada, where the 'Length attribute for arrays expands to the same code as that
for len. As this is all simple integer code without any aliasing issues, I have
some hope that GCC can do better here.

Regards,
  -Geert 

cat lenzero.c && gcc -O3 -fomit-frame-pointer -save-temps -c lenzero.c && otool
-tv lenzero.o
int len(int f, int l) {
 return l < f ? 0 : l - f + 1;
}

int lenzero(int f, int l) {
 return len(f, l) == 0;
}

int lenzero2(int f, int l) {
 return l < f;
}

lenzero.o:
(__TEXT,__text) section
_len:
xorl%eax,%eax
0002cmpl%edi,%esi
0004jl0x000b
0006subl%edi,%esi
0008leal0x01(%rsi),%eax
000brepz/ret
000dnop
000enop
_lenzero:
0010cmpl%esi,%edi
0012movl$0x0001,%eax
0017jg0x0023
0019subl%edi,%esi
001bxorl%eax,%eax
001dcmpl$0xff,%esi
0020sete%al
0023repz/ret
0025nop
0026nopw%cs:0x(%rax,%rax)
_lenzero2:
0030xorl%eax,%eax
0032cmpl%edi,%esi
0034setl%al
0037ret

[Bug tree-optimization/47004] missed optimization in comparison

[bosch at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47004

Geert Bosch  changed:

   What|Removed |Added

 CC||bosch at gcc dot gnu.org

--- Comment #1 from Geert Bosch  2010-12-18 19:22:13 
UTC ---
The compiler gets really close in being able to optimize this testcase.
In fact, adding an extra always-true expression, as I did in lenzero4,
causes the compiler to optimize correctly.

int lenzero3 (int f, int l) {
  return (l < f ? 0 == 0 : l - f + 1 == 0);
}
int lenzero4 (int f, int l) {
  return (l < f ? 0 == 0 : (l - f >= 0) && (l - f + 1 == 0));
}

The first generates:
_lenzero3:
0040cmpl%edi,%esi
0042movl$0x0001,%eax
0047jl0x0053
0049subl%edi,%esi
004bxorl%eax,%eax
004dcmpl$0xff,%esi
0050sete%al
0053repz/ret

The second:
_lenzero4:
0060xorl%eax,%eax
0062cmpl%edi,%esi
0064setl%al
0067ret

The extra condition (l - f >= 0), provides the compiler with the right
hint to do the optimization. It can prove this added condition is always
true, and it then can derive that the condition (l - f + 1 == 0) is
always false.

So, the compiler *can* prove l < f implies l - f >= 0, it just doesn't
know it should prove it in order to optimize the expression in lenzero3.

  -Geert

[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin

[bosch at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411

Geert Bosch  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.22 12:08:12
 CC||bosch at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Geert Bosch  2011-01-22 12:08:12 
UTC ---
I've confirmed that reverting Richard's patch to tree-ssa-ccp.c restores
bootstrap.

  -Geert

[Bug ada/51483] [4.7 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation

[bosch at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483

--- Comment #5 from Geert Bosch  2012-01-10 02:55:46 
UTC ---
If I understand correctly, you're changing the interface to pass the object
size (Esize) instead of the precision (RM_Size). That is not correct.

Right now, we have the assumption that we can derive the Esize from the RM_Size
rounded up to the alignment. What I don't quite understand right now is what
the properties of the M68K type are. What is the precision, size and alignment?

If necessary, we can pass both Esize and RM_Size, but the current change seems
like it would break other targets.

  -Geert