From: Pekka Enberg <penberg@kernel.org>
To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-sparse@vger.kernel.org, Christopher Li <sparse@chrisli.org>,
Jeff Garzik <jgarzik@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/2] sparse, llvm: group PHI nodes at the top of each BB
Date: Tue, 16 Oct 2012 20:59:27 +0300 [thread overview]
Message-ID: <CAOJsxLEEBYMF4qcyBSpS7kaumzpQFm0McNexRtft3UJVwp==Xg@mail.gmail.com> (raw)
In-Reply-To: <CAOJsxLE=UsuonXVPuDxL9jPGQj_M5xdvCUrk5u+m3U-s4Ao-hA@mail.gmail.com>
On Fri, Oct 12, 2012 at 9:25 PM, Pekka Enberg <penberg@kernel.org> wrote:
> On Wed, Oct 10, 2012 at 7:33 PM, Jonathan Neuschäfer
> <j.neuschaefer@gmx.net> wrote:
>> I can't say with certainty that it's safe either, so I probably should
>> have marked the patch with "request for comments".
>>
>> AFAICT there are three reasons an instruction cannot be moved up or down
>> within a basic block:
>> 1. If it takes previous SSA values as arguments, it can't be moved
>> above the corresponding intructions.
>> 2. If its value is used as an argument of an instruction further down
>> in the BB, it can't be moved below that instruction.
>> 3. Swapping two instructions that influence or are influenced by the
>> "global state" (sorry for the loose wording), e.g. by doing memory
>> accesses, performing I/O, or calling functions (which in turn can
>> do about anything in general), is generally unsafe.
>>
>> Case 1 doesn't apply because PHI nodes don't use values computed in the
>> same invocation of their basic block. Case 2 doesn't apply as I'm not
>> moving the PHI nodes down. Case 3 doesn't seem to apply either.
>>
>> That's how I think this patch is safe.
>
> Sounds plausible but I'm still uneasy with the idea that LLVM backend
> needs to reshuffle instructions like this.
>
> Would it be possible to solve this in the frontend?
Linus, Chris, any thoughts on this?
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-10-16 17:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 23:34 [PATCH 1/2] sparse, llvm: group PHI nodes at the top of each BB Jonathan Neuschäfer
2012-10-09 23:34 ` [PATCH 2/2] sparse, llvm: Fix type of loaded values Jonathan Neuschäfer
2012-10-10 0:13 ` Jeff Garzik
2012-10-10 6:34 ` Pekka Enberg
2012-10-10 0:12 ` [PATCH 1/2] sparse, llvm: group PHI nodes at the top of each BB Jeff Garzik
2012-10-10 6:31 ` Pekka Enberg
2012-10-10 16:33 ` Jonathan Neuschäfer
2012-10-12 18:25 ` Pekka Enberg
2012-10-16 17:59 ` Pekka Enberg [this message]
2012-10-16 20:14 ` Jonathan Neuschäfer
2012-10-16 20:53 ` Xi Wang
2012-10-17 6:48 ` Pekka Enberg
2012-10-17 6:53 ` Xi Wang
2012-10-17 16:41 ` Pekka Enberg
2012-10-17 17:44 ` Jonathan Neuschäfer
2013-05-15 12:05 ` Pekka Enberg
2013-05-16 5:28 ` Xi Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOJsxLEEBYMF4qcyBSpS7kaumzpQFm0McNexRtft3UJVwp==Xg@mail.gmail.com' \
--to=penberg@kernel.org \
--cc=j.neuschaefer@gmx.net \
--cc=jgarzik@pobox.com \
--cc=jgarzik@redhat.com \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).