This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Do not remove labels with LABEL_PRESERVE_P
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 24 Sep 2014 14:47:15 +0200
- Subject: Re: [PATCH] Do not remove labels with LABEL_PRESERVE_P
- Authentication-results: sourceware.org; auth=none
- References: <20140919193604 dot GA48001 at msticlxl57 dot ims dot intel dot com> <541C8C0C dot 8040300 at redhat dot com> <CABu31nN-HZ_qYM4N2w_dstwehmvwTj66XMNB=jfHerwj4NdBXQ at mail dot gmail dot com> <54219A77 dot 70403 at redhat dot com> <CAMbmDYb5zVfQb98WJ40pJy9rYkUFBB-=es1ZHzSemB8f73HAqA at mail dot gmail dot com> <CABu31nMK5UmJtKCMZYC2bb7fLbsGMrej4hmB2H-2BpQqEbbpcQ at mail dot gmail dot com> <CAMbmDYYw1-wqEDRAWycqbHCA5RXzuTZBJdE-X_s=-dbA5wAw4g at mail dot gmail dot com> <CABu31nPgUy-pBJuROKuxuON+LxEsJSiMOZ_6_a0nEixE-gkrLQ at mail dot gmail dot com> <CAMbmDYZcDpmM_YZHRgD=wHvAv6QpZjjvxXepNcVmsR=Y5q36eA at mail dot gmail dot com>
On Wed, Sep 24, 2014 at 2:30 PM, Ilya Enkovich wrote:
> I didn't generate references separately from label. Now I found an
> old patch and a test where this problem appeared. In this patch I
> moved set_rip generation currently performed in ix86_expand_prologue
> into expand pass. And I got following code in expand dump for
> testsuite/gcc.target/i386/pr55154.c test:
>
> (note 7 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (note/s 2 7 3 2 "" NOTE_INSN_DELETED_LABEL 2)
> (insn 3 2 4 2 (set (reg:DI 85)
> (unspec:DI [
> (label_ref [2 deleted])
> ] UNSPEC_SET_RIP))
> /export/users/ienkovic/issues/4161/gcc/gcc/testsuite/gcc.target/i386/pr55154.c:9
> -1
> (insn_list:REG_LABEL_OPERAND 2 (nil)))
>
> There is a REG_LABEL_OPERAND generated but label is still removed.
Because it should be a REG_LABEL_TARGET?
AFAUI this is a contol flow insn so I'd expect it to be a jump_insn
(and the note will be a TARGET note). But it's not a PC-set insn and a
jump target the compiler will interpret as an infinite loop (if the
insns are really in the order as above) which is clearly not what you
want. So if you emit it as a jump_insn I'm not sure what will
happen...
Is it necessary to emit the label into a basic block?
Ciao!
Steven