Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86

2005-06-24 Thread fjahanian
On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote: I wonder why combine can do the simplification though which is why still produce good code for the simple testcase: void f1(double *d,float *f2) { *f2 = 0.0; *d = 0.0; } It is hard to reproduce the simple test case, exhibiting the same

Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86

2005-06-30 Thread fjahanian
On Jun 24, 2005, at 5:06 PM, Steven Bosscher wrote: On Saturday 25 June 2005 01:48, fjahanian wrote: On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote: I wonder why combine can do the simplification though which is why still produce good code for the simple testcase: void f1(double *d,float

Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86

2005-06-30 Thread fjahanian
On Jun 24, 2005, at 5:20 PM, fjahanian wrote: On Jun 24, 2005, at 5:06 PM, Steven Bosscher wrote: On Saturday 25 June 2005 01:48, fjahanian wrote: On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote: I wonder why combine can do the simplification though which is why still produce good

Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86

2005-06-30 Thread fjahanian
On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote: On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote: Hmm. I would suspect this is obsolete now. We'll have forced everything into "registers" (or something equivalent that we can work with) during tree optimization. Any CSEs that ca