Unless in gcc-world outermode has the meaning of innermode? (and vice
versa)
which.. from looking at some other source... perhaps it does.. :-/
"Dylan Cuthbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Ok, I think I found out why gen_subreg crashes here: (with gcc 3.3.3)
if
I tried simplify_gen_subreg but it crashes with a compiler error. Maybe
because V4SF isn't really thought of as a subreg of a V16SF at the moment?
I am using gcc 3.3.3 right now so it might be just that it works in a later
version of the compiler?
"Richard Sandiford" <[EMAIL PROTECTED]> wrote
Ok, I think I found out why gen_subreg crashes here: (with gcc 3.3.3)
if (byte % GET_MODE_SIZE (outermode)
|| byte >= GET_MODE_SIZE (innermode))
abort ();
This check doesn't seem right to me ;-)
I'll see what's in the latest cvs for this function.
Regards
Dylan
"Richard Sandiford" <[EMAIL
Thanks for the info...
I was worried about the aliasing problems - adjust_address fits the ticket
perfectly.
The information for simplify_gen_subreg is a little sparse, what does it do
differently to gen_rtx_subreg?
Regards
Dylan
"Richard Sandiford" <[EMAIL PROTECTED]> wrote in message
news:[E
"Dylan Cuthbert" <[EMAIL PROTECTED]> writes:
>emit_move_insn( gen_rtx_SUBREG (V4SFmode, op0, 0 ), gen_rtx_MEM(
> V4SFmode, src_reg ) );
>emit_move_insn( gen_rtx_SUBREG (V4SFmode, op0, 16 ), gen_rtx_MEM(
> V4SFmode, plus_constant( src_reg, 16 ) ) );
>emit_move_insn( gen_rtx_SUBREG (V4SF
Ah, ok, sorry about that, I read it as being the equivalent of the whole
operation.
I'll throw op1 in there, thanks again.
Dylan
"James E Wilson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am puttin
Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am putting in
"gen_rtx_SET ( V16SFmode, op0, op1 )", does this seem correct to you?
This is supposed to be the value of op0 after the no conflict block. So
it should just be op1.
--
Jim Wilson, GNU Tools Support, ht
Brilliant!
This got rid of the warnings, *and* got rid of the spurious move I was
getting. Thanks for the advice!
The problem with the spurious move was with the move from memory to the
v16sf register, because it was doing it with subregs it thought it still had
to preserve the previous (unini
Dylan Cuthbert wrote:
The assembler instructions themselves don't allow the target to be the
same as the source unfortunately so removing the '&' is difficult. (If
I enforce the same thing without a '&' in inline asm using builtins and
building the expression manually to generate a new reg rtx
Dylan Cuthbert wrote:
Is there someway I can flag the moves to say that is moving the v16sf
"whole" so it doesn't need to be initialised and hence avoid the warning?
See emit_no_conflict_block in optabs.c.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
One reason that occurred to me is that I am issueing the v16sf move as four
subreg v4sf moves.
One thing I get are "variable may not be initialised" warnings:
v16sf test;
test = _builtin_matrix_mul( left, right );
return test;
Is there someway I can flag the moves to say that is moving the v16s
Hi there,
The assembler instructions themselves don't allow the target to be the same
as the source unfortunately so removing the '&' is difficult. (If I enforce
the same thing without a '&' in inline asm using builtins and building the
expression manually to generate a new reg rtx if the dest/
Dylan Cuthbert wrote:
> asm( "some_instruction %0,%1,%2,%3" : "=&j" (blob): "j" (vec1), "j"
> (vec2), "j" (frog) );
> asm( "some_instruction2 %0,%1" : "=&j" (frog) : "j" (blob) );
It is the goal of the register allocator to use as few registers as
possible,
which means that we will try to use the
Further investigation.
If I remove the define_expand for movv16sf and throw in a dummy define_insn
that supports reg<->reg mem<->reg reg<->mem, then the redundant move is
optimized away.
But of course, the store load and move all use 4 instructions each so this
produces in
Hi there,
I have implemented a move of a v16sf type like this because it is held by 4
v4sf registers:
--- snip ---
(define_expand "movv16sf"
[(set (match_operand:V16SF 0 "nonimmediate_operand" "")
(match_operand:V16SF 1 "general_operand" ""))]
""
" if ((
15 matches
Mail list logo
