On 6/24/20 4:15 PM, Richard Biener wrote:
On Wed, Jun 24, 2020 at 11:27 AM Martin Liška wrote:
On 6/24/20 11:09 AM, Richard Biener wrote:
On Wed, Jun 24, 2020 at 10:49 AM Martin Liška wrote:
On 6/24/20 9:43 AM, Richard Biener wrote:
Hmm, can you instead use simple_dce_from_worklist and si
On Wed, Jun 24, 2020 at 11:27 AM Martin Liška wrote:
>
> On 6/24/20 11:09 AM, Richard Biener wrote:
> > On Wed, Jun 24, 2020 at 10:49 AM Martin Liška 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_
On 6/24/20 11:09 AM, Richard Biener wrote:
On Wed, Jun 24, 2020 at 10:49 AM Martin Liška 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 hash
On Wed, Jun 24, 2020 at 10:49 AM Martin Liška 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
>
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 d
On Wed, Jun 24, 2020 at 9:21 AM Martin Liška wrote:
>
> Hi.
>
> When expanding a VEC_COND_EXPR it happens that first argument (a SSA_NAME)
> that can be no longer used. When that happens we need to remove the SSA_NAME,
> otherwise we end up expanding it and for targets like s390x, there's no optab
