Re: GC overhead just because of aligning long double?

2009-10-17 Thread Richard Guenther
On Sun, 18 Oct 2009, Richard Guenther wrote: > > We're waisting 8 bytes for every gimple_seq_node_d on x86_64 just > because we might be allocating a structure with a long double > element (16 byte aligned). I grepped and didn't find traces of > such a use, so - can we just document that callers

GC overhead just because of aligning long double?

2009-10-17 Thread Richard Guenther
We're waisting 8 bytes for every gimple_seq_node_d on x86_64 just because we might be allocating a structure with a long double element (16 byte aligned). I grepped and didn't find traces of such a use, so - can we just document that callers need to round up allocation sizes to multiples of the r

__attribute__((optimize)) and fast-math related oddities

2009-10-17 Thread tbp
Hang on while i put on my flame-proof suit. There. Merrily trying to make a test-case showing how unmanageable it is to try to override *math* flags per function, i soon had to stop because... $ cat amusing.cc #include static __attribute__((optimize("-fno-associative-math"))) double foo1(double x)

Re: Constraint modifier for partially overlaping operands

2009-10-17 Thread Andrew Hutchinson
Yes. But we need to lower after combine and before register allocation. I'm still figuring out how to do that. Lowering before combine - in particular causes a lot of code bloat. This loose all optimization of conditional jumps, shifts etc. In our case, most lowering is delayed until after relo

Re: Constraint modifier for partially overlaping operands

2009-10-17 Thread Dave Korn
Andrew Hutchinson wrote: > OR partial overlap is preferred (or required) Oh, I see what you mean. Yes, that probably would be useful, thanks for the clarification. cheers, DaveK

Re: Constraint modifier for partially overlaping operands

2009-10-17 Thread Richard Henderson
On 10/16/2009 11:04 PM, Ian Lance Taylor wrote: Andrew Hutchinson writes: I can use "=" modifier to make operands use same register and early clobber "&" to avoid overlaps. Is it possible to have or construct a contraint that permits partial overlap operands. (which neither = or& would allow

Re: Constraint modifier for partially overlaping operands

2009-10-17 Thread Andrew Hutchinson
The situation comes up where no or a partial overlap of registers permits optimal code - since this can avoid using scratch register Thus no overlap OR partial overlap is preferred (or required) Using nothing leaves overlap without preference - full, partial,none Using = gives the least preff

Re: Constraint modifier for partially overlaping operands

2009-10-17 Thread Dave Korn
Ian Lance Taylor wrote: > Andrew Hutchinson writes: > >> I can use "=" modifier to make operands use same register and early >> clobber "&" to avoid overlaps. >> >> Is it possible to have or construct a contraint that permits partial >> overlap operands. (which neither = or & would allow) >> The

Re: Bug in binop rotate ?

2009-10-17 Thread Andrew Hutchinson
Thanks for your review. I have submitted bug report. Richard Guenther wrote: On Sat, Oct 17, 2009 at 3:47 PM, Andrew Hutchinson wrote: I have been adding rotate capability to AVR port and have come across what I think is bug in optabs.c: expand_binop() This occurs during a rotate expans

Re: Bug in binop rotate ?

2009-10-17 Thread Richard Guenther
On Sat, Oct 17, 2009 at 3:47 PM, Andrew Hutchinson wrote: > I have been adding rotate capability to AVR port and have come across what I > think is bug in > optabs.c: expand_binop() > > This occurs during a rotate expansion. For example > > target  = op0  rotated by op1 > > In the particular situa

Bug in binop rotate ?

2009-10-17 Thread Andrew Hutchinson
I have been adding rotate capability to AVR port and have come across what I think is bug in optabs.c: expand_binop() This occurs during a rotate expansion. For example target = op0 rotated by op1 In the particular situation (code extract below) it tries a reverse rotate of (bits - op1). Wh

Re: Alias analysis or DSE problem?

2009-10-17 Thread Richard Guenther
On Sat, Oct 17, 2009 at 12:44 AM, Justin Seyster wrote: > I'm currently porting a plug-in that used to target the 4.3.0-based > plug-in branch to the new top-of-tree plug-in system.  I'm really > stymied by a bug whose source I just cannot track down!  Usually that > means there is an error in my