[LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

Smith, Kevin B kevin.b.smith at intel.com
Tue Feb 24 10:26:14 PST 2015


FWIW, since I am not really much of a contributor to LLVM.

The points Chandler makes for why passes must be allowed to create dead code are excellent.  Dead code elimination is a general compiler cleanup
pass, do be run once in a while to get rid of code that for whatever reasons is dead.  Every pass should not have to police themselves not to produce dead code.
This strategy (of having independent passes to do well-defined specific things) is pretty much (it seems to me) one of the founding principles of LLVM design,
and one of its very key strengths.  Dead code elimination should not be built into all other passes.

Hal gets to the heart of the matter (in my opinion) when he writes:

Ø   2. Should unreachable code be allowed to contain nonsense (like instructions that depend on themselves)? To this, I believe the answer is no. We currently permit this, and I think that a lot of the bugs regarding unreachable code some from this. I've yet to hear a good argument why, for example, JumpThreading must produce self-referential instructions in trivially-dead regions.

To me this looks like an example of incorrect SSA IR.  SSA form is not supposed to allow for the case of a use of a def where the def cannot reach.  And my understanding was that “undef” LLVM IR was created exactly for specifying cases where a def was required for proper SSA form, but where none was available.
Clearly ( to me at least), an instruction cannot use in its inputs a def that occurs later in the same basic-block (and that includes the def the instruction itself defines).
That would either need to be an undef, or a phi that merges an undef and the def that occurs later.

Years ago (late 90s, early 2000s) the Intel compiler had quite a few problems with SSA form that could be traced to somewhat undisciplined handling of
“undefined” defs, PHI removal, and this type of degenerate SSA.  We did as is being suggested currently for LLVM, and made such IR illegal, and changed
our internal verifiers to catch those.  After a short time, this shook loose some remaining bugs with mishandling of SSA form, and improved compiler stability
in this regard.  I think that is an excellent direction for LLVM infrastructure to go in.

Kevin B. Smith
Intel Compiler Team

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Monday, February 23, 2015 11:05 PM
To: Hal Finkel
Cc: Katya Romanova; LLVM Developers Mailing List; Rafael Espindola
Subject: Re: [LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

Will try to reply to the larger thread again soon, but a quick reply on a bit of a tangent...

On Mon, Feb 23, 2015 at 8:45 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote:
 2. Should unreachable code be allowed to contain nonsense (like instructions that depend on themselves)? To this, I believe the answer is no. We currently permit this, and I think that a lot of the bugs regarding unreachable code some from this. I've yet to hear a good argument why, for example, JumpThreading must produce self-referential instructions in trivially-dead regions.

I could easily see tightening the rules on what passes the verifier within unreachable code to try to make it substantially cheaper, easier, and less error prone to handle unreachable code. It seems likely that there are good pragmatic compromises here that would actually cost nothing. Obvious example is, as you highlight, self-referential non-phi instructions could easily just be rejected, and asserted during construction by the IR builder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/ab456ebc/attachment.html>


More information about the llvm-dev mailing list