Hello Mike Stump,
Thanks for your comment.
I'll remove all of redundant code for this target.
I wonder that what paper is?
Is it an introduction about new feature in our target?
On Wed, Jan 27, 2016 at 5:53 AM, Mike Stump <mikest...@comcast.net> wrote:
> I don’t see the point of libgcc/config/vn8/test.patch. I suspect either you
> need to apply it to your diffs before you send them out, or remove the file a
> junk from the diff set.
>
> I saw:
>
> inflating: libgcc/config/vn8/lib1funcs-fixed.S
> inflating: libgcc/config/vn8/lib1funcs-fixed.S.old
> inflating: libgcc/config/vn8/lib1funcs.S
> inflating: libgcc/config/vn8/lib1funcs.S.old
>
> and suspect the .old files are old, and aren’t used by the build. If so,
> they can be removed.
>
> I saw:
>
> inflating: gcc/config/vn8/vn8.md.bak
> inflating: gcc/config/vn8/vn8.md.bk
> inflating: gcc/config/vn8/t-vn8.bak
>
> and suspect these aren’t needed (or are badly named) and should be removed.
>
> I glanced at the non-port files, and all that code looks fine.
>
>> I used gcc-4.9.0 version for new port.
>
> So, you will want to check out a copy of the compiler from git or svn. You
> will want to do this checkout from the trunk. You then want to apply your
> patch set to it, and build and test it, fixing any issues that arise, and
> then contribute that. The patch set you sent would be a back port to a
> release branch, if any, and would come after the port is accepted into trunk.
>
>> // output_addr_const (stderr, addr);
>> // fprintf(stderr,"\n”);
>> // rtx temp_rtx = XEXP(XEXP(x,0),0);
>
> It is now time to figure out what to do with this code. If you like it and
> want to keep it, instead do:
>
> #define PORTDEBUGGING 0
>
> if (PORTDEBUGGING)
> {
> }
>
> and turn it into normal code.
>
>> #if 0
>> ADJUST_BYTESIZE (QI, 1);
>> ADJUST_BYTESIZE (HI, 1);
>> ADJUST_BYTESIZE (SI, 2);
>> ADJUST_BYTESIZE (PSI, 3);
>> ADJUST_BYTESIZE (DI, 4);
>> ADJUST_BYTESIZE (TI, 8);
>> #endif // 1
>
> You should just remove the whole block.
>
>
> I’d recommend fixing all the above and reposting. Someone else will do a
> more in depth port review and comment further.
>
> If you don’t have your paper work done, you will want to start up that
> process now. The port can’t go into the compiler without it.
>
>
>
> One last comment, while you wait for the review of the port code, you should
> consider your FIXMEs and decide if there is any progress you can make on them.
>
> ./gcc/config/vn8/vn8.c: /* FIXME: For setjmp and in
> vn8_builtin_setjmp_frame_value we don't know
> ./gcc/config/vn8/vn8.c: /* FIXME: Non-generic addresses are not
> mode-dependent in themselves.
> ./gcc/config/vn8/vn8.c: /* FIXME: We ship info on failing tail-call in
> struct machine_function.
> ./gcc/config/vn8/vn8.c: /* FIXME: For OS_task and OS_main, this might be
> over-conservative. */
> ./gcc/config/vn8/vn8.c: /* FIXME: Ideally, the following test is not needed.
> ./gcc/config/vn8/vn8.c: /* FIXME: This hook gets called with MODE:REGNO
> combinations that don't
> ./gcc/config/vn8/vn8.c: FIXME: Filter out cases where the target object
> is known to
> ./gcc/config/vn8/vn8.c: /* FIXME: Register allocator might come up with
> spill fails if it is left
> ./gcc/config/vn8/vn8.c: /* FIXME: Register allocator does a bad job and
> might spill address
--
Thanks & Best regards
Nguyễn Sinh Ngọc
Software Department
IC Design & Research Education Center
Email: ngoc.nguyens...@icdrec.edu.vn
Cell Phone: +84 (0)974117946
