RFC: Handling of libgcc symbols in SH shared libraries

[Rakesh Kumar, Noida]

Hi there,

  I sent this patch to the mailing list. But mail was blocked due to improper
content format. I'm resending the patch to the list.

> That's a non sequitur.  To write an optimized assembler function, you have
> to consider the different algorithms available, and for all the likely
> candidates, see how the needed computations and data flow requirements
> constrain the scheduling of the 'hot' paths through the code, and do your
> instruction selection and scheduling around these constraints.
> When you have enough information to definitely say that one version is
> inferior, you can drop it.

Well, ours is one way to emulate [fd]p-bit.c, with some advantages and disadvantages.
You can reuse the code wherever you need. You can evaluate the approaches
used and submit the better one.

> Then what is the meaning of the blank lines interspersed with the instructions?

We have paired the instructions which are issued at one cycle separated by
a blank line. There are some exceptions with TEST and BRANCH instructions.

Best Regards,
Rakesh Kumar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: double-paranoia-results
Type: application/octet-stream
Size: 6954 bytes
Desc: double-paranoia-results
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040811/8e33732f/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-fp.txt
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040811/8e33732f/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: single-paranoia-results
Type: application/octet-stream
Size: 7008 bytes
Desc: single-paranoia-results
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040811/8e33732f/attachment-0001.obj>