On 6/24/20 4:15 PM, Richard Biener wrote:
On Wed, Jun 24, 2020 at 11:27 AM Martin Liška <mli...@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 <mli...@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.
All right, I'm going to push a patch with that changed.
Martin
Richard.
Thanks,
Martin
Richard.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
