Zoltan Somogyi ab297c220d Eliminate mostly-duplicate work in frameopt.m.
compiler/frameopt.m:
    The key decision in frame optimization is "which basic blocks need
    a stack frame"?

    One aspect of this decision is that if a block needs a frame,
    then all successors of that block will get a frame. We therefore
    unconditionally propagate the need for a frame forwards.

    Another aspect is that if all the successors of a block need a frame,
    then it is better for that block to allocate a frame than for
    all its successors to do so, since this saves space, and does not
    cost any time. We therefore *conditionally* propagate the need
    for a frame backwards.

    This diff speeds up conditional propagation to predecessors
    by processing each predecessor just once, which reduces the
    complexity of the algorithm from quadratic to linear. This speeds
    up the compilation of options.m by about 13%.

    This change can change the output slightly (because the result of the
    "do all successors of this predicate need a frame" test can change
    as the algorithm learns more about frames), but it seems that
    in practice, this happens only very rarely, and even then
    its impact on the performance of the generated code is negligible.

    The code doing propagation to successors already had a mechanism
    to handle each block just once. Speed up this mechanism also by
    switching the "have we done this block already" test from using
    plain sets (O(N) lookup) to using set_tree234s (O(log N) lookup).

    Also improve some minor aspects of programming style.
2025-11-26 14:33:23 +11:00
2025-09-23 12:56:11 +10:00
2025-11-07 10:46:09 +11:00
2025-10-10 15:30:49 +11:00
2025-11-01 16:50:02 +11:00

Mercury

Mercury is a logic/functional programming language which combines the clarity and the expressiveness of declarative programming with advanced static analysis and error detection features.

More information is available on the website's about pages, in other README files in the source code repository, and in the documentation.

Small sample programs written in Mercury can be found in the samples and extras directories of the source code repository.

README files

The Mercury compiler has two different backends and works on different operating systems. Specific information is contained in individual README files:

Other information

See the current release notes for the latest stable release. The news file lists any recent changes. The history file is relevant if you want to find out more about the past development of Mercury. The limitations file lists some ways in which the Mercury implementation does not yet meet its goals.

Information for developers

If you are considering contributing to the Mercury project, the website contains some documents that may be helpful. These include a document about contributions in general and specific information about contributing such as coding styles.

Contact

See our contact page.

Description
No description provided
Readme MIT 247 MiB
Languages
Mercury 85.5%
C 8.7%
Shell 1.2%
Makefile 1%
JavaScript 1%
Other 2.1%