On 07/11/16 17:04, Bernd Schmidt wrote:
On 11/03/2016 03:00 PM, Eric Botcazou wrote:
FWIW here's a more complete version of my patch which I'm currently
testing. Let me know if you think it's at least a good enough
intermediate step to be installed.
It is, thanks.
Testing showed the same i
On 11/03/2016 03:00 PM, Eric Botcazou wrote:
FWIW here's a more complete version of my patch which I'm currently
testing. Let me know if you think it's at least a good enough
intermediate step to be installed.
It is, thanks.
Testing showed the same issue as Jiong found, so I've committed it w
On 03/11/16 13:01, Bernd Schmidt wrote:
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 241233)
+++ gcc/emit-rtl.c (working copy)
@@ -6169,17 +6169,18 @@ emit_copy_of_insn_after (rtx_insn *insn,
which may be
> FWIW here's a more complete version of my patch which I'm currently
> testing. Let me know if you think it's at least a good enough
> intermediate step to be installed.
It is, thanks.
> I think, the sel-sched example notwithstanding, this is something that
> normally should not be needed outsid
On 11/03/2016 01:33 PM, Eric Botcazou wrote:
Thanks for the feedback, I'll try to work through this.
Thanks, but since there doesn't seem to be a consensus on the goal, feel free
to disregard it and just implement what you need for your initial work.
FWIW here's a more complete version of my
> Thanks for the feedback, I'll try to work through this.
Thanks, but since there doesn't seem to be a consensus on the goal, feel free
to disregard it and just implement what you need for your initial work.
--
Eric Botcazou
On 03/11/16 12:06, Eric Botcazou wrote:
What's your decision on this?
I think that we ought to standardize on a single order for note copying in the
RTL middle-end and the best way to enforce it is to have a single primitive in
rtlanal.c, with an optional filtering. Bernd's patch is a step
>What's your decision on this?
I think that we ought to standardize on a single order for note copying in the
RTL middle-end and the best way to enforce it is to have a single primitive in
rtlanal.c, with an optional filtering. Bernd's patch is a step in the right
direction, but doesn't en
On 21/10/16 13:30, Bernd Schmidt wrote:
On 10/21/2016 02:04 PM, Jiong Wang wrote:
+ /* Locate the end of existing REG_NOTES in NEW_RTX. */
+ rtx *ptail = ®_NOTES (new_rtx);
+ while (*ptail != NULL_RTX)
+ptail = &XEXP (*ptail, 1);
I was thinking along the lines of something like this
On 10/21/2016 02:04 PM, Jiong Wang wrote:
+ /* Locate the end of existing REG_NOTES in NEW_RTX. */
+ rtx *ptail = ®_NOTES (new_rtx);
+ while (*ptail != NULL_RTX)
+ptail = &XEXP (*ptail, 1);
I was thinking along the lines of something like this (untested,
emit-rtl.c part omitted). Eri
On 21/10/16 11:13, Bernd Schmidt wrote:
On 10/21/2016 09:43 AM, Eric Botcazou wrote:
I disagree: there are currently n ways of copying NOTEs in the RTL
middle-end,
with different properties each time. We need only one primitive in
rtlanal.c.
I feel the fact that they have different propertie
On 10/21/2016 09:43 AM, Eric Botcazou wrote:
I disagree: there are currently n ways of copying NOTEs in the RTL middle-end,
with different properties each time. We need only one primitive in rtlanal.c.
I feel the fact that they have different properties means we shouldn't
try to unify them: w
On 21/10/16 08:43, Eric Botcazou wrote:
That's also overcomplicated.
Yes, I agree that's too heavy.
rtx *ptail = ®_NOTES (to_insn);
while (*ptail != NULL_RTX)
ptail = &XEXP (*ptail, 1);
Thanks very much Bernd, yes, this is better. And through manipulating
pointer directly, those bidire
> That's also overcomplicated.
Yes, I agree that's too heavy.
> rtx *ptail = ®_NOTES (to_insn);
> while (*ptail != NULL_RTX)
>ptail = &XEXP (*ptail, 1);
>
> gives you a pointer to the end which you can then use to append,
> unconditionally. As mentioned above, I think it would be simpler to
On 10/20/2016 05:28 PM, Jiong Wang wrote:
This patch makes EXPR_LIST/INST_LIST/INT_LIST insertion bi-directional,
the new
node can be inserted to either the start or the end of the given list.
I can't help but feel that this is somewhat more complicated than it
needs to be.
One thing to note
As discussed on PR middle-end/78016, here is the patch.
This patch makes EXPR_LIST/INST_LIST/INT_LIST insertion bi-directional, the new
node can be inserted to either the start or the end of the given list.
The existed alloc_EXPR_LIST, alloc_INSN_LIST becomes wrapper of new
bi-directional functi
16 matches
Mail list logo
