Re: negative latencies
On 21-May-14 06:30 PM, Vladimir Makarov wrote: I am just curious what happens when you put insn2, insn1. and insn2 uses a result of insn1 in 6 cycles and insn1 producing the result in 3 cycles, but there are not ready functional units (e.g. arithmentic units) necessary for insn1 for 4 or more cycles. It is quite not trivial to guarantee that everything will be okay in general case if you put insn2 before insn1. This is not a problem for this architecture. The units are fully pipelined and the only conflicts are in the first stage, during instruction issue. That is, the vliw must be legal. The gcc dfa handles this case fine.
Re: negative latencies
On 22-May-14 07:21 PM, Bernd Schmidt wrote: On 05/21/2014 05:30 PM, Vladimir Makarov wrote: On 2014-05-20, 5:18 PM, shmeel gutl wrote: The problem that I see is that the haifa scheduler schedules one cycle at a time, in a forward order, by picking from a list of instructions that can be scheduled without delays. So, in the above example, if instruction one is scheduled during cycle 3, it can't schedule instruction two during cycle 0, 1, or 2 because its producer dependency (instruction one) hasn't been scheduled yet. It won't be able to schedule it until cycle 3. So I am asking if there is an existing mechanism to back schedule instruction two once instruction one is issued. I see, thanks. There is no such mechanism in the current insn scheduler. Well, the scheduler has support for an exposed pipeline that is used by the C6X port. Insns are split into multiple pieces which are forced to be scheduled at a fixed distance in time from each other, each piece describing the effects that occur at that point in time. This could probably be made to work for this target's requirements, but it might run quite slowly. Bernd Exposed pipeline is not my problem. Negative latency is my problem. I don't see negative latency for c6x, not in unit reservations and not in adjust cost. Did I miss something? Shmeel
Re: negative latencies
On 05/23/2014 10:07 AM, shmeel gutl wrote: Exposed pipeline is not my problem. Negative latency is my problem. I don't see negative latency for c6x, not in unit reservations and not in adjust cost. Did I miss something? You just need to model it differently. Rather than saying instruction A has a negative latency relative to instruction B, you need to describe that instruction B reads its inputs later than when it is actually issued. The mechanism used in the C6X backend is the scheduler's record_delay_slot_pair function. The scheduler would see B is issued (*) A is issued, executes and writes its outputs B reads its inputs (*) The two insns marked as (*) would be such a delay pair. The first one would generate code, the second one exists only for the purposes of building the right scheduling dependencies. Bernd
Re: gcc 4.8.3 / PR60901
On 22 May 2014 16:12, Kenny Simpson wrote: > PR60901 is listed in the bug fixes for gcc 4.8.3, but I don't see the patch > ever applied to the 4_8 branch in the bug report, The PR shouldn't have been closed without either changing the Target Milestone or backporting the patch to the release branches. > and 4.8.3 is listed as known to fail. That's not /necessarily/ a contradiction, 4.8.3-prerelease failed and if it was fixed for the final release the Target Milestone would say 4.8.3 ... but in this case the Target Milestone is wrong and misleading.
Re: negative latencies
On 2014-05-23, 3:49 AM, shmeel gutl wrote: On 21-May-14 06:30 PM, Vladimir Makarov wrote: I am just curious what happens when you put insn2, insn1. and insn2 uses a result of insn1 in 6 cycles and insn1 producing the result in 3 cycles, but there are not ready functional units (e.g. arithmentic units) necessary for insn1 for 4 or more cycles. It is quite not trivial to guarantee that everything will be okay in general case if you put insn2 before insn1. This is not a problem for this architecture. The units are fully pipelined and the only conflicts are in the first stage, during instruction issue. That is, the vliw must be legal. The gcc dfa handles this case fine. Another problem is that besides insn-scheduler there are a lot of optimizations which can insert some insns between the two insns after scheduling. In this case the result might be not ready for insn2. So you at least should exclude 1st insn scheduling (before RA) and make 2nd insn scheduling as the very last pass. In general, a traditional approach is to do such things on assembler level (e.g. as for older MIPS processor without hardware interlocks).
use of sphinx/rest as source for GNAT doc
At AdaCore, we have switched most of our product documentation the rest/sphinx format: http://sphinx-doc.org/ which provides most of the advantages of texinfo (text format, can generate output in multiple formats, supported by free software), as well as additional advantages, at least for us (more modern output, actively maintained, support more output formats, simpler syntax). So we are investigating converting also the GNAT documentation (GNAT User's Guide and GNAT RM) to this format. I understand that GCC as whole likely wants to stick with texinfo for the time being, so I'm not really suggesting a switch here, but what about the following approach: - the GNAT doc source would be in rest format (.rst files) instead of texinfo (.texi files) - we would still provide .texi files, generated automatically by the sphinx toolset (via 'make texinfo') and committed in the repository (similarly to configure vs configure.in/aclocal.m4), so end users would not have any extra dependency, and generation of documentation would still be possible from the .texi files directly What do people think in principle about the above proposal? Would that be an acceptable move for the GCC project? Arno
Re: use of sphinx/rest as source for GNAT doc
On 05/23/14 09:23, Arnaud Charlet wrote: At AdaCore, we have switched most of our product documentation the rest/sphinx format: http://sphinx-doc.org/ which provides most of the advantages of texinfo (text format, can generate output in multiple formats, supported by free software), as well as additional advantages, at least for us (more modern output, actively maintained, support more output formats, simpler syntax). So we are investigating converting also the GNAT documentation (GNAT User's Guide and GNAT RM) to this format. I understand that GCC as whole likely wants to stick with texinfo for the time being, so I'm not really suggesting a switch here, but what about the following approach: - the GNAT doc source would be in rest format (.rst files) instead of texinfo (.texi files) - we would still provide .texi files, generated automatically by the sphinx toolset (via 'make texinfo') and committed in the repository (similarly to configure vs configure.in/aclocal.m4), so end users would not have any extra dependency, and generation of documentation would still be possible from the .texi files directly What do people think in principle about the above proposal? Would that be an acceptable move for the GCC project? Given the long term maintenance issues around texlive/texinfo, investigation of other formats is wise. The fact that sphinx can generate .texi files is a huge win from a flexibility standpoint. I'd support this as a pilot for converting the entire project. The generated .texi files should have some kind of comment marker indicating they are generated from the .rst files and how to recreate them so that other maintainers can DTRT with the Ada docs as necessary. Jeff
Re: use of sphinx/rest as source for GNAT doc
Thanks for the quick feedback! > Given the long term maintenance issues around texlive/texinfo, > investigation of other formats is wise. The fact that sphinx can > generate .texi files is a huge win from a flexibility standpoint. Indeed. We've been looking for a possible replacement format for texinfo for years at AdaCore with no success, and have finally found sphinx and started using it. After several years of experience with sphinx I must say we are very pleased. > I'd support this as a pilot for converting the entire project. The > generated .texi files should have some kind of comment marker > indicating they are generated from the .rst files and how to > recreate them so that other maintainers can DTRT with the Ada docs > as necessary. Yes, definitely. We would provide all means to use sphinx directly as an option (e.g. sphinx Makefiles or support files) so that everyone can do e.g. 'make texinfo' or 'make html ' if they want to. Arno
Re: use of sphinx/rest as source for GNAT doc
On Fri, 2014-05-23 at 17:23 +0200, Arnaud Charlet wrote: > At AdaCore, we have switched most of our product documentation the > rest/sphinx format: http://sphinx-doc.org/ > which provides most of the advantages of texinfo (text format, > can generate output in multiple formats, supported by free software), as well > as additional advantages, at least for us (more modern output, actively > maintained, support more output formats, simpler syntax). > > So we are investigating converting also the GNAT documentation > (GNAT User's Guide and GNAT RM) to this format. > > I understand that GCC as whole likely wants to stick with texinfo > for the time being, so I'm not really suggesting a switch here, but > what about the following approach: > > - the GNAT doc source would be in rest format (.rst files) instead > of texinfo (.texi files) > - we would still provide .texi files, generated automatically by the > sphinx toolset (via 'make texinfo') and committed in the repository > (similarly to configure vs configure.in/aclocal.m4), so end users > would not have any extra dependency, and generation of documentation > would still be possible from the .texi files directly > > What do people think in principle about the above proposal? > Would that be an acceptable move for the GCC project? FWIW I too use sphinx and .rst, for the gcc-python-plugin: https://gcc-python-plugin.readthedocs.org/en/latest/index.html and for pygccjit, the python bindings to the JIT branch: http://pygccjit.readthedocs.org/en/latest/ [the above both use a custom "skin" provided by readthedocs.org, but the default looks great also]. [For that matter the LLVM project uses sphinx also]. Having used both sphinx and texinfo, I find that Sphinx is far superior to texinfo in both the editing experience (emacs has modes for both .rst and .texi) and in the quality of the generated HTML (e.g. stable, readable URLs). My 2 cents Dave
Re: use of sphinx/rest as source for GNAT doc
On 05/23/2014 05:23 PM, Arnaud Charlet wrote: - the GNAT doc source would be in rest format (.rst files) instead of texinfo (.texi files) What about the preprocessor for the VMS specifics? Will it go away? - we would still provide .texi files, generated automatically by the sphinx toolset (via 'make texinfo') and committed in the repository (similarly to configure vs configure.in/aclocal.m4), so end users would not have any extra dependency, and generation of documentation would still be possible from the .texi files directly How stable is the output from Sphinx across versions? Will this potentially cause a lot of update churn? -- Florian Weimer / Red Hat Product Security Team
Re: use of sphinx/rest as source for GNAT doc
> >- the GNAT doc source would be in rest format (.rst files) instead > > of texinfo (.texi files) > > What about the preprocessor for the VMS specifics? Will it go away? Yes, we are about to baseline VMS maintenance, and the VMS specific doc will go away in any case. > >- we would still provide .texi files, generated automatically by the > > sphinx toolset (via 'make texinfo') and committed in the repository > > (similarly to configure vs configure.in/aclocal.m4), so end users > > would not have any extra dependency, and generation of documentation > > would still be possible from the .texi files directly > > How stable is the output from Sphinx across versions? Will this > potentially cause a lot of update churn? I do not know, that can be investigated, although it's no different from e.g. using different versions of autoconf (or requiring a specific version). Arno
