> If this usage isn't legitimate, and the CALL_ARG_LOCATION is supposed
> to come directly after the call, then it would be great if someone more
> familiar with the var-tracking code could have a look at it.
"Be liberal in what you accept" says the common wisdom.
> gcc/
> * emit-rtl.c (try
Richard Sandiford writes:
> gcc/
> PR rtl-optimization/48826
> * emit-rtl.c (try_split): When splitting a call that is followed
> by a NOTE_INSN_CALL_ARG_LOCATION, move the note after the new call.
It turns out that this isn't enough. In the attached testcase,
we have a:
(
> It sounded like you were more concerned with having the comments staying
> in sync than the actual specifics, so I went ahead and installed the
> patch below.
That's fine, thanks.
--
Eric Botcazou
Eric Botcazou writes:
>> PR rtl-optimization/48826
>> * emit-rtl.c (try_split): When splitting a call that is followed
>> by a NOTE_INSN_CALL_ARG_LOCATION, move the note after the new call.
>
> OK if you move up the comment and merge it in the comment of the
> block. And it would b
> PR rtl-optimization/48826
> * emit-rtl.c (try_split): When splitting a call that is followed
> by a NOTE_INSN_CALL_ARG_LOCATION, move the note after the new call.
OK if you move up the comment and merge it in the comment of the block. And it
would be nice to add the missing b
In PR 44826, we split a pre-reload call into another call followed
by a load of GP. The problem is that we're running the split pass after
var-tracking, and the original call had a NOTE_INSN_CALL_ARG_LOCATION
attached to it. We need to move the note to the new call, just like we
already move othe
