llvm-project/llvm/test/CodeGen/Generic/2008-02-04-ExtractSubvector.ll

; RUN: llvm-as < %s | llc

define i32 @main() nounwind  {
entry:
	br label %bb15

bb15:		; preds = %bb15, %entry
	%tmp21 = fadd <8 x double> zeroinitializer, zeroinitializer		; <<8 x double>> [#uses=1]
	br i1 false, label %bb30, label %bb15

bb30:		; preds = %bb15
	store <8 x double> %tmp21, <8 x double>* null, align 64
	ret i32 0
}
Crashes LegalizeTypes with "Do not know how to split this operator's operand" (node: extract_subvector). llvm-svn: 46712 2008-02-05 02:05:42 +08:00			`; RUN: llvm-as < %s \| llc`

			`define i32 @main() nounwind {`
			`entry:`
			`br label %bb15`

			`bb15: ; preds = %bb15, %entry`
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897 2009-06-05 06:49:04 +08:00			`%tmp21 = fadd <8 x double> zeroinitializer, zeroinitializer ; <<8 x double>> [#uses=1]`
Crashes LegalizeTypes with "Do not know how to split this operator's operand" (node: extract_subvector). llvm-svn: 46712 2008-02-05 02:05:42 +08:00			`br i1 false, label %bb30, label %bb15`

			`bb30: ; preds = %bb15`
			`store <8 x double> %tmp21, <8 x double>* null, align 64`
			`ret i32 0`
			`}`