Bug 60651 - Mode switching instructions are sometimes emitted in the wrong order
Summary: Mode switching instructions are sometimes emitted in the wrong order
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks: 60824
  Show dependency treegraph
 
Reported: 2014-03-25 13:21 UTC by Jorn Wolfgang Rennecke
Modified: 2014-04-11 18:47 UTC (History)
0 users

See Also:
Host:
Target: epiphany-*-*
Build:
Known to work: 4.10.0
Known to fail: 4.9.0
Last reconfirmed:


Attachments
patch (921 bytes, patch)
2014-03-25 13:47 UTC, Jorn Wolfgang Rennecke
Details | Diff
preprocessed libjava file (91.07 KB, text/plain)
2014-04-02 16:47 UTC, Jorn Wolfgang Rennecke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2014-03-25 13:21:08 UTC
As dicussed at http://forums.parallella.org/viewtopic.php?f=13&t=1053&sid=2d28ee29b5dd3c591d947074f46ac752&p=6654#p6654, this code:

int a;
int c;

void __attribute__((interrupt))
misc_handler (void) {
   a*= c;
}

Is compiled into code that uses an uninitialized register.
As it turns out, the interrupt attribute is actually a red herring (as long as you use the default of (-mfp-mode=caller).
The problem is that, after emitting the mask-loading instruction, mode
switching emits the mode switch to the caller's mode which uses that mask
*before* the load of the mask, thus using the register uninitialized.
The mask loading instruction, thus rendered useless, is later deleted.

The things with lcm is that we have an algorithm that can be a bit expensive,
but we can process multiple entities at almost no extra cost.
The epiphany needs to load constants to do its mode switching; these constants
can be anticipated further up in the dominance graph.  This can be modelled
as having a different entity for each mask needed, the need for which is
indicated at the same point as the mode switch itself.  Because the mask
load entities are not subject to transparency issues (except in the unfortunate
case of abnormal edges), lcm can move the loads up in suitable dominator
positions.
The modes priorities on the epiphany are also such that the mask loads have a
mode with the same or higher priority as the mask uses.
Also, the mask loads have lowered numbered entities than the mask uses.
As the lcm part of optimize_mode_switching inserts, for each priority, the
mode setting in ascending order of entities, and insert_insn_on_edge
appends to the currently registered sequence, this works find there.
The segment-based code also preserves entity order when inserting before an instruction.
However, when inserting after a basic block head, later inserted mode
switch instructions end up prior to ones earlier inserted into the insn
stream.
To preserve the order, in the case of an initially empty basic block,
what we have to do is append the new instructions at the end of the basic
block.
Comment 1 Jorn Wolfgang Rennecke 2014-03-25 13:47:00 UTC
Created attachment 32447 [details]
patch

The attached patch implements this aforementioned insertion at the end
of an (initially) empty basic block.
I'm currently bootstrapping/regtesting this on i686-pc-linux-gnu
Comment 2 Jorn Wolfgang Rennecke 2014-04-02 16:47:07 UTC
Created attachment 32526 [details]
preprocessed libjava file

With the latest proposed patch, we get an assertion failure building libjava
during the i686-pc-linux-gnu bootstrap; this is the command line:

./cc1plus -fpreprocessed interpret.ii -quiet -dumpbase interpret.cc -mtune=generic -march=pentiumpro -auxbase-strip .libs/interpret.o -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -ffloat-store -fomit-frame-pointer -fwrapv -fPIC -o interpret.s

The block in question looks like this:

(code_label/s 9087 9590 9090 17 990 "" [1 uses])

(note 9090 9087 9088 17 [bb 17] NOTE_INSN_BASIC_BLOCK)

where the BB_HEAD is the CODE_LABEL, and the BB_END is the NOTE_INSN_BASIC_BLOCK.

The caller of new_seginfo is the abnormal-edge code that I've patched to
handle non-empty blocks differently; this block is mistaken for a non-empty
block.

Now, interestingly, the pre-existing code already handles this incorrectly,
by inserting instructions between the CODE_LABEL an the NOTE_INSN_BASIC_BLOCK.
Comment 3 Jorn Wolfgang Rennecke 2014-04-11 14:38:10 UTC
This patch:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00091.html
has been approved for gcc4.10, modulo one spelling fix:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00263.html
Comment 4 Jorn Wolfgang Rennecke 2014-04-11 18:13:25 UTC
Author: amylaar
Date: Fri Apr 11 18:12:53 2014
New Revision: 209312

URL: http://gcc.gnu.org/viewcvs?rev=209312&root=gcc&view=rev
Log:
gcc:
        PR rtl-optimization/60651
        * mode-switching.c (optimize_mode_switching): Make sure to emit
        sets of a lower numbered entity before sets of a higher numbered
        entity to a mode of the same or lower priority.
        When creating a seginfo for a basic block that starts with a code
        label, move the insertion point past the code label.
        (new_seginfo): Document and enforce requirement that
        NOTE_INSN_BASIC_BLOCK only appears for empty blocks.
        * doc/tm.texi.in: Document ordering constraint for emitted mode sets.
        * doc/tm.texi: Regenerate.
gcc/testsuite:
        PR rtl-optimization/60651
        * gcc.target/epiphany/mode-switch.c: New test.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/tm.texi
    trunk/gcc/doc/tm.texi.in
    trunk/gcc/mode-switching.c
    trunk/gcc/testsuite/ChangeLog
Comment 5 Jorn Wolfgang Rennecke 2014-04-11 18:28:17 UTC
Author: amylaar
Date: Fri Apr 11 18:27:45 2014
New Revision: 209318

URL: http://gcc.gnu.org/viewcvs?rev=209318&root=gcc&view=rev
Log:
gcc/testsuite:
        PR rtl-optimization/60651
        * gcc.target/epiphany/mode-switch.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/epiphany/mode-switch.c
Comment 6 Jorn Wolfgang Rennecke 2014-04-11 18:47:23 UTC
Fixed with commits of comment #4/#5.