[llvm-commits] [llvm] r74991 - in /llvm/trunk: docs/ include/llvm-c/ include/llvm/ include/llvm/Bitcode/ include/llvm/Support/ lib/Analysis/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/SelectionDAG/ lib/Target/ARM/ lib/Tran

[Nick Lewycky]

2009/7/7 Chris Lattner <clattner at apple.com>

>
> On Jul 7, 2009, at 8:04 PM, Nick Lewycky wrote:
>
> > Author: nicholas
> > Date: Tue Jul  7 22:04:38 2009
> > New Revision: 74991
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=74991&view=rev
> > Log:
> > Remove the vicmp and vfcmp instructions. Because we never had a
> > release with
> > these instructions, no autoupgrade or backwards compatibility
> > support is
> > provided.
>
> Nice!
>
> > +++ llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h Tue Jul  7
> > 22:04:38 2009
> > @@ -210,7 +210,8 @@
> >     FUNC_CODE_INST_GETRESULT   = 25, // GETRESULT:  [ty, opval, n]
> >     FUNC_CODE_INST_EXTRACTVAL  = 26, // EXTRACTVAL: [n x operands]
> >     FUNC_CODE_INST_INSERTVAL   = 27, // INSERTVAL:  [n x operands]
> > -    // fcmp/icmp returning Int1TY or vector of Int1Ty, NOT for
> > vicmp/vfcmp
> > +    // fcmp/icmp returning Int1TY or vector of Int1Ty. Same as CMP,
> > exists to
> > +    // support legacy vicmp/vfcmp instructions.
> >     FUNC_CODE_INST_CMP2        = 28, // CMP2:       [opty, opval,
> > opval, pred]
>
> Can this just be removed?
>

No. The code as released in LLVM 2.5 had basically no correlation between
whether the instruction was [if]cmp or v[if]cmp and whether INST_CMP or
INST_CMP2 was used. The comment was only there to confuse the reader.

As of this commit, we only generate INST_CMP2 which has a better chance of
being read correctly by previous versions of LLVM than if we were to
generate INST_CMP.

To make matters worse, some 2.5 version bitcode files would contain icmp
(but not fcmp?) with a bad type, such as a constant expression icmp that
returns <4 x i32> instead of <4 x i1>. Such files will no longer load with
current LLVM; we could try to autoupgrade those but I'm inclined to say
"sorry, older LLVMs were buggy and produced bad IR in rare circumstances"
than to try to deal with it.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090708/36b60626/attachment.html>