colinb2 . wrote on 07/12/2018 12:03 PM:
On 7/12/18, U.Mutlu <um@xxxxxxxxxxx> wrote:
colinb2 . wrote on 07/12/2018 02:52 AM:
Do you mean the make file created by the configure script of gcc,
or do you mean a self-made makefile?
I mean the make file created by the configure script of gcc; I think
I am - at least for now - incapable of writing my own script!
I just tried to make GCC-8.1.0 and that fell over after about 30 minutes!
https://gcc.gnu.org/ml/gcc/2018-07/msg00159.html
I couldn't figure out yet which hdcode (ie. that of the book) you refer
in the msg00159-link above (or have I maybe overlooked your reference?).
I don't have that book. Can you give the ref-link please if it's among
the codes published at the web site under
http://hackersdelight.org/hdcode.htm
http://hackersdelight.org/hdcodetxt/magicu.c.txt
This is magicu aand magicu2 in "Hacker's Delight" by Henry S Warren;
choose_multiplier_v4 in is my (hopefully improved) version of magicu2.
Ok, thx, got it now.
So, you have an improved algorithm that could replace a slower one in gcc.
It's this function in gcc_src/gcc/expmed.c :
unsigned HOST_WIDE_INT
choose_multiplier (unsigned HOST_WIDE_INT d, int n, int precision,
unsigned HOST_WIDE_INT *multiplier_ptr,
int *post_shift_ptr, int *lgup_ptr)
The question is: have you tested it in practice? Ie. replacing the one
in your local gcc source and building the new compiler and running the
testsuite tests ("make -j -k check" etc).
Or asked differently: what is the current status? Does it just need
to be implemented (added to repo), or is your improvement still open
for some discussion/debate and still needs some stress-testing by the
people to show that it's indeed better?
Usually people submit a patch file (ie. a diff file) in the mailing list
gcc-patches (s. https://gcc.gnu.org/lists.html ), so that others can
automatically (by applying the patch) import the code into their local
gcc source, review, rebuild the compiler and run the tests in the testsuite.
Afterwards, if the tests are positive, one of the admins (s. MAINTAINERS
file) needs to approve the patch to be checked-in into the repository.
So, as I'm not one of the MAINTAINERS myself yet, I would suggest that
you should be clear about these procedures, and perhaps contact a
MAINTAINER directly, or at least one of the developers who has worked
on the said file(s) (expmed.c etc) and its functions; ie. do some (re)search
in the mailing list archives, and maybe also in the bug tracking database
at https://gcc.gnu.org/bugzilla/
As can be seen: a better/faster algorithm alone is not sufficient enough;
it must also be peer-reviewed, discussed, rigourosly tested, and hopefully
finally get approval.
Last but not least: all contributions must also conform to some
Coding Standards, see details under "Contributing to GCC" at
https://gcc.gnu.org/contribute.html
--
U.Mutlu
