llvm-project/llvm/test/Transforms/GlobalOpt/2008-01-29-VolatileGlobal.ll

; RUN: opt %s -globalopt -S | grep {volatile load}
@t0.1441 = internal global double 0x3FD5555555555555, align 8		; <double*> [#uses=1]

define double @foo() nounwind  {
entry:
	%tmp1 = volatile load double* @t0.1441, align 8		; <double> [#uses=2]
	%tmp4 = fmul double %tmp1, %tmp1		; <double> [#uses=1]
	ret double %tmp4
}
Use opt -S instead of piping bitcode output through llvm-dis. llvm-svn: 81257 2009-09-09 06:34:10 +08:00			`; RUN: opt %s -globalopt -S \| grep {volatile load}`
Don't let globalopt hack on volatile loads or stores. llvm-svn: 46523 2008-01-30 03:01:37 +08:00			`@t0.1441 = internal global double 0x3FD5555555555555, align 8 ; <double*> [#uses=1]`

			`define double @foo() nounwind {`
			`entry:`
			`%tmp1 = volatile load double* @t0.1441, align 8 ; <double> [#uses=2]`
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			`%tmp4 = fmul double %tmp1, %tmp1 ; <double> [#uses=1]`
Don't let globalopt hack on volatile loads or stores. llvm-svn: 46523 2008-01-30 03:01:37 +08:00			`ret double %tmp4`
			`}`