On 26 March 2014 08:15, Eric Botcazou <ebotca...@adacore.com> wrote:
>> As described in the PR, this patch fixes a wrong-code bug by making the
>> order of emitted mode switching instructions more consistet & predictable.
>
> I don't understand this change (but I'm not a specialist of mode switching):
> currently the mode setting sequence is always emitted before the insns that
> need it but, with the change, if an insn right after a NOTE_BASIC_BLOCK note
> needs it, if will be emitted either before it (if insn_ptr is the insn) or
> after it (if insn_ptr is the NOTE_BASIC_BLOCK note).

When the seginfo is for an initially empty block, appending the mode
switching instruction at the end is fine.
Now that I'm trying to prove that this is always the case when insn_ptr
is set to a a NOTE_INSN_BASIC_BLOCK, I find that is not actually true.
insn_ptr gets set in new_seginfo, and there are three calls to that function.
The second call is for instructions that themselves need a particular mode,
so these are not basic block heads.  The third call is for and BB_END, and
this is a NOTE_INSN_BASIC_BLOCK exactly iff the block is empty.

However, the first call is for blocks with incoming abnormal edges.
If these are empty, the change as I wrote it yesterday is fine, but not
when they are non-empty; in that case, we should indeed insert before the
first instruction in that block.

This can be archived by finding an insert-before position using NEXT_INSN
on the basic block head; this amounts to the very same insertion place
as inserting after the basic block head.  Also, we will continue to set no
location, and use the same bb, because both add_insn_before and
add_insn_after (in contradiction to its block comment) will infer the basic
block from the insn given (in the case for add_insn_before, I assume
that the basic block doesn't start with a BARRIER - that would be invalid -
and that the insn it starts with has a valid BLOCK_FOR_INSN setting the
same way the basic block head has.

bootstrapped on i686-pc-linux-gnu, regtest in progress.

Attachment: tmp
Description: Binary data

Reply via email to