llvm dev - Nov 2010 - [LLVMdev] Two questions about creating a new target

Hi list,

I am in the process of creating a new target in LLVM/Clang for a
custom 16-bit machine. My initial goal is to configure Clang so that
when LLVM bytecode (or assembly) is generated, the integer size is 16
bits.

After defining an appropriate TargetInfo subclass (where integer size
is set to 16) the generated LLVM assembly looks almost correct,
however one of the parameters for getelementptr still gets passed as a
32-bit integer:

%1 = load i16* getelementptr inbounds ([5 x i16]*
@myfunc.auto.myvector, i32 0, i16 0)

This fact disturbs me slightly, because it means that Clang somehow
still "thinks" that the target has the notion of 32-bit variables
(which is incorrect). Could anyone give me a hint on how to fix it?

Another thing I have noticed... this is more a curiosity about Clang
internals :-) When I generate code using x86 as target, variables are
allocated with "alloca", but when I use my target they are simply
declared as auto-variables. Is there any way to get the same
allocation that is used for x86?

Thanks,
Lorenzo

On Tue, Nov 9, 2010 at 6:04 PM, Lorenzo De Carli <lorenzo at cs.wisc.edu>
wrote:
> Hi list,
>
> I am in the process of creating a new target in LLVM/Clang for a
> custom 16-bit machine. My initial goal is to configure Clang so that
> when LLVM bytecode (or assembly) is generated, the integer size is 16
> bits.
>
> After defining an appropriate TargetInfo subclass (where integer size
> is set to 16) the generated LLVM assembly looks almost correct,
> however one of the parameters for getelementptr still gets passed as a
> 32-bit integer:
>
> %1 = load i16* getelementptr inbounds ([5 x i16]*
> @myfunc.auto.myvector, i32 0, i16 0)
>
> This fact disturbs me slightly, because it means that Clang somehow
> still "thinks" that the target has the notion of 32-bit variables
> (which is incorrect). Could anyone give me a hint on how to fix it?
AFAICT, the index in question comes from
CodeGenFunction::EmitArraySubscriptExpr in CGExpr.cpp, which I think
was written without really paying attention to the type used for the
index.  In this case, it's harmless; zero is zero no matter its width.
 That said, feel free to submit a patch to cfe-commits.  (And in the
future, please provide C code as an example.)
> Another thing I have noticed... this is more a curiosity about Clang
> internals :-) When I generate code using x86 as target, variables are
> allocated with "alloca", but when I use my target they are simply
> declared as auto-variables. Is there any way to get the same
> allocation that is used for x86?
You'll have to be more specific here; that doesn't sound like
something that should vary by target.  Can you provide a simple C
testcase and the generated IR to show the issue?

On a side note, this is more appropriate for cfe-dev; I'm redirecting
the discussion there.

-Eli