[cfe-dev] Variable declaration on custom target

Lorenzo De Carli lorenzo at cs.wisc.edu
Wed Nov 10 12:18:55 PST 2010


Hi list,

I am working on a custom 16-bit target for Clang. I have defined an
appropriate TargetInfo object in Targets.cpp, and I am able to get
16-bit LLVM assembly from Clang. However, I noticed that variables
declared in a function body are treated differently when compiling for
X86 and for my architecture. In particular, on X86 such variables are
treated as virtual registers while on the custom target they are
declared as auto-variables. For example, if I compile the following
code:

int myfunc(int param) {
  int val;
  int result;

  val = 5;
  result = val * param;

  return result;
}

on X86 I get:

; ModuleID = 'myfunc.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

define i32 @myfunc(i32 %param) nounwind {
  %1 = alloca i32, align 4
  %val = alloca i32, align 4
  %result = alloca i32, align 4
  store i32 %param, i32* %1, align 4
  store i32 5, i32* %val, align 4
  %2 = load i32* %val, align 4
  %3 = load i32* %1, align 4
  %4 = mul nsw i32 %2, %3
  store i32 %4, i32* %result, align 4
  %5 = load i32* %result, align 4
  ret i32 %5
}

while on my custom target I get:

target datalayout =
"e-p:16:16:16-i16:16:16-f16:16:16-n16:16:16-v16:16:16-a16:16:16"
target triple = "myarch-myvendor-myos"

@myfunc.auto.val = internal global i16 0, align 2
@myfunc.auto.result = internal global i16 0, align 2

define i16 @myfunc(i16 %param) nounwind {
  %1 = alloca i16, align 2
  store i16 %param, i16* %1, align 2
  store i16 5, i16* @myfunc.auto.val, align 2
  %2 = load i16* @myfunc.auto.val, align 2
  %3 = load i16* %1, align 2
  %4 = mul nsw i16 %2, %3
  store i16 %4, i16* @myfunc.auto.result, align 2
  %5 = load i16* @myfunc.auto.result, align 2
  ret i16 %5
}

Could someone explain why this is happening? (I already asked a
similar question on LLVM-dev, but Eli recommended
me to re-post on cfe-dev).

Thanks,
Lorenzo



More information about the cfe-dev mailing list