On Jun 30, 2005, at 12:47 PM, Steven Bosscher wrote:
Well, maybe so, but it would be a pretty lame workaround. Why are you
so worried about bugs? This flag was always disabled at -O1, and we
have never seen any bug reports that got fixed with -fforced-mem. And
besides, it is better to fix b
On Thursday 30 June 2005 21:05, Fariborz Jahanian wrote:
> On Jun 30, 2005, at 11:23 AM, Jeffrey A Law wrote:
> > On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
> >> Jeffrey A Law wrote:
> >>> I'd tend to agree. I'd rather see the option go away than linger on
> >>> if the option is no lo
On Jun 30, 2005, at 11:23 AM, Jeffrey A Law wrote:
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out tha
Joe Buck <[EMAIL PROTECTED]> wrote:
>>> I'd tend to agree. I'd rather see the option go away than linger on
>>> if the option is no longer useful.
>>
>> I wouldn't mind that, but I'd also like to point out that there are
>> Makefiles out there which hard-code things like -fforce-mem. Do we want
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> > I'd tend to agree. I'd rather see the option go away than linger on
> > if the option is no longer useful.
>
> I wouldn't mind that, but I'd also like to point out that there are
> Makefiles out there which hard-c
On Thu, Jun 30, 2005 at 08:12:14PM +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> >I'd tend to agree. I'd rather see the option go away than linger on
> >if the option is no longer useful.
>
> I wouldn't mind that, but I'd also like to point out that there are
> Makefiles out there which h
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out that there are
Makefiles out there which hard-code things like -fforce-mem. Do we want
to keep the option as a stu
On Thu, 2005-06-30 at 18:55 +0200, Steven Bosscher wrote:
> On Thursday 30 June 2005 18:05, fjahanian wrote:
> > 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
>
On Thursday 30 June 2005 18:05, fjahanian wrote:
> 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
>
On Jun 30, 2005, at 12:05 PM, fjahanian wrote:
Bootstrapped and dejagnu tested on apple-x86-darwin and
apple-ppc-darwin.
We also observed that on ppc, SPEC did not show any performance change
either way. On apple-x86-darwin 252.eon improved by 7% as expected,
with no noticeable change in oth
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
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 co
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
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 can be
made should have been made.
I will do sanity chec
On Mon, Jun 27, 2005 at 12:21:01PM -0700, Fariborz Jahanian wrote:
> FYI, the change to rtl in -O2 vs. -O1 is that -O2 includes -fforce-
> mem which forces memory operands to registers to make memory
> references common sub-expressions.
Hmm. I would suspect this is obsolete now. We'll have f
FYI, the change to rtl in -O2 vs. -O1 is that -O2 includes -fforce-
mem which forces memory operands to registers to make memory
references common sub-expressions. In this case, the constant double
float value is assigned to an xmm register which is used where it is
needed. So, I would say
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 *f2)
> > {
> > *f2 = 0.0;
> > *d = 0.0
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
On Jun 24, 2005, at 6:07 PM, Fariborz Jahanian wrote:
A source file mrSurfaceList.cc of 252.eon produces less efficient code
initializing instance objects to 0 at -O2 than at -O1. Behavior is
random and it does not happen on all x86 platforms and making the
test smaller makes the problem go
A source file mrSurfaceList.cc of 252.eon produces less efficient
code initializing instance objects to 0 at -O2 than at -O1. Behavior
is random and it does not happen on all x86 platforms and making the
test smaller makes the problem go away. But here is what I found out
is the cause.
W
20 matches
Mail list logo
