[PATCH] VEC_COND_EXPR: clean up first argument
Richard Biener
richard.guenther@gmail.com
Wed Jun 24 14:15:11 GMT 2020
On Wed, Jun 24, 2020 at 11:27 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 6/24/20 11:09 AM, Richard Biener wrote:
> > On Wed, Jun 24, 2020 at 10:49 AM Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 6/24/20 9:43 AM, Richard Biener wrote:
> >>> Hmm, can you instead use simple_dce_from_worklist and simply
> >>> record all SSA_NAMEs you end up "forwarding" as possibly dead
> >>> in a bitmap? At least that hashmap traversal looks dangerous
> >>> with respect to address-space randomization and gsi_remove
> >>> inserting debug stmts and thus eventually allocating debug decls.
> >>
> >> Sure, done in the updated patch.
> >
> > You can simplify the patch by eliding the num_imm_uses checks
>
> Really? How can I be sure that a SSA_NAME is not shared among different
> VEC_COND_EXPR statements (or even by some other statements)?
The bitmap DCE does this check for you.
> > and by using auto_bitmap.
>
> Oh yeah!
>
> > Why is it necessary to update
> > the veclower pass btw? Is that just to avoid useless isels
> > on dead code?
>
> Yes:
>
> _10 = _9 != { 0, 0, 0, 0 };
> _11 = *a_16(D);
> _12 = *b_17(D);
> _13 = _11 + _12;
> _14 = VEC_COND_EXPR <_10, _13, { 3.0e+0, 3.0e+0, 3.0e+0, 3.0e+0 }>;
>
> is expanded by vectlower to something like:
>
> _10 = _9 != { 0, 0, 0, 0 };
> _11 = *a_16(D);
> _12 = *b_17(D);
> _67 = BIT_FIELD_REF <_11, 32, 0>;
> _68 = BIT_FIELD_REF <_12, 32, 0>;
> _69 = _67 + _68;
> ...
> _14 = {_80, _82, _84, _86};
> *a_16(D) = _14;
>
> So one needs to remove: _10 = _9 != { 0, 0, 0, 0 };
> Note the ICE happens without an optimization level.
Ah, OK. That makes sense.
>
> >
> > You also updated veclower "nicely" but still have the hashmap
> > walk in isel - you should know when you "merged" a condition
> > into a cond and set the bit there.
>
> Isn't the same as before as the first argument can be actually shared in between
> multiple GIMPLE statements?
As said above the bitmap DCE is built for lazy consumption.
Richard.
> Thanks,
> Martin
>
> >
> > Richard.
> >
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >> Thanks,
> >> Martin
> >>
>
More information about the Gcc-patches
mailing list