This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: do we ever thread computed gotos?
- From: Jeff Law <law at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 26 Oct 2017 06:52:22 -0600
- Subject: Re: do we ever thread computed gotos?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4A06F5DA08
- References: <0a239d0e-7ae8-5e33-2e32-e553bdb8b3ee@redhat.com>
On 10/26/2017 05:05 AM, Aldy Hernandez wrote:
> Howdy.
>
> In the backwards threader we attempt to thread paths that lead to a
> basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a
> GIMPLE_GOTO. The latter doesn't make much sense, since we only handle
> constants. What does a goto to a constant mean? Does that ever happen?
When we're able to thread a computed goto, we should be threading to an
ADDR_EXPR or LABEL_EXPR. Threading to a constant just doesn't make sense.
However, we have to filter that case reasonably -- there's certainly a
test in the testsuite where a computed jump can be threaded to a
constant. THe DOM threader aborted/faulted on that in the past.
So I wouldn't lose any sleep if we just didn't handle computed gotos in
the backwards threader and left it to DOM to catch the rare cases were
we can thread to a label/decl.
Jeff