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
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
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
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
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
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
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
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
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
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)
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
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
12 matches
Mail list logo
