On 09/24/2015 09:19 AM, Abe wrote:
On 9/24/15 1:07 AM, Jeff Law wrote:
So what that means is the presence or absence of debug information is
causing a difference in
> the code you generate. That is (of course) bad and indicates a bug
of some kind in your code.
I haven't put your code under a debugger or anything like that, but
this does jump out:
+ rtx_insn* temp_src_insn = BB_HEAD (then_bb);
+ if (temp_src_insn && NOTE_INSN_BASIC_BLOCK_P (temp_src_insn))
+ temp_src_insn = NEXT_INSN (temp_src_insn); /* skip over a
start-of-BB note */
What if BB_HEAD (then_bb) is a DEBUG_INSN with -g enabled, but is a
NOTE_INSN_BASIC_BLOCK when -g is not enabled. That could cause
this kind of failure.
Thanks very much! I`m just checking email right before heading out to
surgery, so I can`t experiment on changing the above code right now, but
I`ll be sure to do so next week.
After some thinking, I thought of this question: would "-g"/"-g3"/etc.
cause a DEBUG_INSN to be present in the RTL as the first insn in the BB,
just before the start-of-BB note? In other words, rather than only
checking to see if I should skip copying the first insn in the BB, would
checking {the first insn, and if that`s not a NOTE, then check the
second insn} and skipping over whichever one is the first "hit" for
"NOTE" be a safe strategy?
I'd be surprised if we had DEBUG_INSNs as the first insn in a block
(before the note), but it can't hurt to verify. I believe cfgrtl checks
for proper location of the block note. But maybe I'm mis-remembering.
It might not be a bad idea to run the verification code immediately
after your transformation (for testing purposes only).
Otherwise, you're just going to have to slog through and find out why
the codegen is different. These kind of bugs are usually painful to
track down, but it's usually worth the time spent in the end.
jeff
