[PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)

[Seongbae Park (박성배, 朴成培)]

On 10/19/07, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Oct 19, 2007 at 11:03:00AM -0700, Seongbae Park (박성배, 朴成培) wrote:
> > > insns with UNSPECs inside of
> > > PARALLELs is IMHO a regression from 4.2 and as such should be fixed.
> >
> > I'm not sure on this. During the current DCE development,
> > we've asked for what UNSPEC means,
> > and the collective answer we got was what's described in rtl.def.
>
> That asking was done on IRC, not on the ml.

I'm afraid you might have missed the thread:

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00386.html

I guess the subject wasn't very informative.

> Can you show which backend uses UNSPEC inside of PARALLEL that is not
> deletable?

I can't find the pattern in ia64.md,
but we used to have a regression caused by deleting UNSPEC inside PARALLEL.

> Or was that part added just for symmetricity?

Nope. It was explicitly to fix a regression,
though it's easier if we don't have to distinguish between top level
and inside parallel.

> 4.2 insn_dead_p certainly didn't do anything special about plain UNSPECs,
> though it wasn't run late when ia64 adds those 3 UNSPECs into the RTL chain.
>
> I have quickly skimmed i386, rs6000, sparc, alpha, mips, s390 md files.
> UNSPEC alone
> ia64/ia64.md
> prologue_use
> flushrs
> bundle_selector
>
> I agree about all these 3 that they shouldn't be deletable.
>
> But the uses of UNSPECs inside of PARALLEL I'm pretty sure all are meant to
> mean this insn does what is in the first PARALLEL entry, but does it
> slightly differently (except maybe for s390 UNSPEC_EXECUTE, I'm really not
> sure about that, but if it wouldn't be deletable, guess 4.2 would have
> problems; then UNSPEC_EXECUTE is the only (unspec ) that appears on the
> first position inside of the parallel).  All the rest is IMNSHO deletable.
>
> UNSPEC inside of PARALLEL
> i386/i386.md
> return_internal_long
> tls_global_dynamic_64
> tls_local_dynamic_base_64
> alpha/alpha.md
> sibcall_osf_1_er
> sibcall_osf_1
> rs6000/altivec.md
> altivec_lve*
> altivec_lvx*
> altivec_stvx*
> altivec_stve*
> rs6000/spe.md
> spe_evlhhesplat
> spe_evlhhesplatx
> spe_evlhhossplat
> spe_evlhhossplatx
> spe_evlhhousplat
> spe_evlhhousplatx
> spe_evlwhsplat
> spe_evlwhsplatx
> spe_evlwwsplat
> spe_evlwwsplatx
> spe_evldd
> spe_evlddx
> spe_evldh
> spe_evldhx
> spe_evldw
> spe_evldwx
> spe_evlwhe
> spe_evlwhex
> spe_evlwhos
> spe_evlwhosx
> spe_evlwhou
> spe_evlwhoux
> spe_evstdd
> spe_evstddx
> spe_evstdh
> spe_evstdhx
> spe_evstdw
> spe_evstdwx
> spe_evstwhe
> spe_evstwhex
> spe_evstwho
> spe_evstwhox
> spe_evstwwe
> spe_evstwwex
> spe_evstwwo
> spe_evstwwox
> s390/s390.md
> UNSPEC_EXECUTE
> UNSPEC_ROUND
>
>         Jakub

I looked at those and I agree.
I just don't know this will work in ia64 - if ia64 maintainers can agree
to allow deleting insns with UNSPEC at the top of PARALLEL
(of course, provided the insn is dead otherwise), I'm fine with doing
it that way.
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"