Re: [PATCH] [MIPS] [Loongson] Specific integer instructions added ( H ow to test ’prefetchx‘？)

["Ruan Beihong" <ruanbeihong at gmail dot com>]

Thanks for your detailed explanation.
I think now I know how to deal with prefetch insn.
I'm sure that load to $0 doesn't raise any exception.
As to the division insns, (d)div(u).g is faster than (d)div(u).When
both quotient and remainder are needed, a (d)div(u).g followed by a
(d)mod(u).g is slower. But when sequence of quotient and remainder are
needed, the new instructions are a little faster. Considering the case
that single div or mod takes the most share of usage of (d)div(u),
these new instructions is useful.

>Do you have a copyright assignment on file?  We'd need one before we could
accept the patch.

I don't because I don't know how to. I think the files I modified
already have a copyright assignment, and I agree with them. If I
really need to add a assignment, please tell me how and to where.

Thanks.


2008/7/22 Richard Sandiford <rdsandiford@googlemail.com>:
> Hi,
>
> Thanks for the patch.
>
> I suppose I should start with the formalities.  Do you have
> a copyright assignment on file?  We'd need one before we could
> accept the patch.
>
> "Ruan Beihong" <ruanbeihong@gmail.com> writes:
>> This patch is based on gcc-4.4 r137685.
>> Following Loongson 2[E|F] specific integer instructions have been added.
>> multu.g dmultu.g div.g ddiv.g  divu.g ddivu.g mod.g dmod.g modu.g dmodu.g
>> Those instruction execute 3 integer operands mult, div and mod without
>> using or changing HI/LO.
>>
>> By the way, I tried to add prefetch (load to $0 on Loongson) and
>> prefetchx (split to an plus operation and a prefetch),
>>  but I failed to construct a C code which gcc can generate the
>> 'prefetchx'. So I ask for help that some one interested
>> might change this poor patch and test the 'prefetchx' then release a
>> formal patch.
>
> The problem here is that the patch doesn't add any define_insns;
> it only adds a define_split.  define_splits are not used for
> recognising valid insns; they're only used for splitting insns
> into other forms.
>
> So the define_split in your patch is for something that, on Loongson,
> is an invalid instruction.  (In other words, the instruction doesn't
> match a define_insn.)  That's OK: combine uses such define_splits to
> convert an invalid combined instruction into two valid instructions.
> However, the particular define_split you added here isn't really useful
> for that: it simply detects cases where we have combined some instructions
> into the form:
>
>  (prefetch (plus:P (match_operand:P 0 "register_operand" "")
>                    (match_operand:P 1 "register_operand" ""))
>            (match_operand 2 "const_int_operand" "")
>            (match_operand 3 "const_int_operand" ""))
>
> and it splits the instruction into an addition and a prefetch.
> The chances are that that's what we started out with.
>
> Probably not a good explanation, sorry.  The specifics of define_insns
> and define_splits are incidental anyway: the model is that we only
> provide base+index prefetch insns on targets that have them.
> It's up to the target-independent code to legitimise base+index
> addresses on targets that don't have them.  Thus the lack of a
> prefetchx-style define_insn for MIPS III is intentional.
>
> The "prefetch_<mode>_ls2ef" insn shouldn't be needed.
> register_operands are simply a special case of address_operands,
> so everything matched by "prefetch_<mode>_ls2ef" is also
> matched by "prefetch".
>
> I don't have access to Loongson literature, so just to be sure:
> does the Loongson really not raise exceptions for invalid addresses
> when the target of a load is $0?  We can't use a load to $0 if it
> might fault.
>
> As far as the division insns go, do we want to continue to use the
> traditional (d)div(u) if both the quotient _and_ remainder are needed?
> Or do we want to use separate division and modulus instructions?
> (This depends on processor-specific details.)  What does the patch do?
>
> My understanding is that mult(u).g is the only form of 3-operand
> multiplication that Loongson has, so I don't think we need a
> new insn type.  We can just use "imul3".  The multiplication
> stuff looks good otherwise, thanks.
>
> Sorry for all the questions and nitpicks.
>
> Richard
>



-- 
James Ruan