File: imm-range-check.ll

package info (click to toggle)
llvm-toolchain-19 1%3A19.1.7-3~deb12u1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm-proposed-updates
  • size: 1,998,492 kB
  • sloc: cpp: 6,951,680; ansic: 1,486,157; asm: 913,598; python: 232,024; f90: 80,126; objc: 75,281; lisp: 37,276; pascal: 16,990; sh: 10,009; ml: 5,058; perl: 4,724; awk: 3,523; makefile: 3,167; javascript: 2,504; xml: 892; fortran: 664; cs: 573
file content (26 lines) | stat: -rw-r--r-- 1,006 bytes parent folder | download | duplicates (6) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
; RUN: llc -march=hexagon -filetype=obj < %s | llvm-objdump -d - | FileCheck %s

; The output assembly (textual) contains the instruction
;   r29 = add(r29,#4294967136)
; The value 4294967136 is -160 when interpreted as a signed 32-bit
; integer, so it fits in the range of the immediate operand without
; a constant extender. The range check in HexagonInstrInfo was putting
; the operand value into an int variable, reporting no need for an
; extender. This resulted in a packet with 4 instructions, including
; the "add". The corresponding check in HexagonMCInstrInfo was using
; an int64_t variable, causing an extender to be emitted when lowering
; to MCInst, and resulting in a packet with 5 instructions.

; Check that this doesn't crash.
; CHECK: r29 = add(r29,#-0xa0)

target triple = "hexagon-unknown-linux-gnu"

define float @f0() {
b0:
  %v0 = alloca i8, i32 0, align 1
  %v1 = alloca float, i32 -42, align 4
  %v2 = load float, ptr %v1, align 4
  store i8 0, ptr %v0, align 1
  ret float %v2
}