llvm dev - Oct 2013 - [LLVMdev] Runtime Array-Length

All,

I am building my own language with llvm as the base.

I was working on string concatenation (where a string is just an array of
characters cast to a pointer to a character (i8*) ). Given two strings, it
is possible to determine the length of new string by summing the number of
characters until the null terminator and adding one.

Unfortunately, I have no idea how to use the c-api to store this. As the
length of the new string is not a compile-time constant (e.g. stored in a
Value*), I cannot determine at compile-time what length the llvm array-type
will be? Therefore, I cannot create the GlobalVariable since I do not know
the type.

One possible solution I thought of was linking to the malloc function and
calling that, but I'm sure there's a better way. If any of you have
implemented a similar sort of string concatenation, I would much appreciate
any advice that you could give.

Thanks,
Billy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131012/0fea868d/attachment.html>

The toy language I've been playing around with represents all strings as a
struct in llvm;

struct string{
  char *ptr;
  int str_len;
  int buffer_len;
}

And my AST has an interface like;

String_AST{
  int measure();
  void copy(char *dest);
  struct string get_value();
}

A constant string can be measured at compile time, for a string variable
measure() just extracts str_len. Strings passed in from other external
sources are measured immediately, but llvm optimisations will eliminate the
call if the return value isn't used.

The implementation of get_value() for a concatenation AST node can generate
code to evaluate each sub string, measure them, allocate the final buffer
length, and only then copy each sub string directly into the final buffer.

I also support a string append operation that will reallocate the buffer
only if the existing one is too small.

Ultimately you will need to work out if you want pascal / java style
strings like mine, or C style NULL terminated strings. And how the memory
for these strings will be managed.


On Sun, Oct 13, 2013 at 4:43 AM, William Moses <
moses.williamsteven at gmail.com> wrote:
> All,
>
> I am building my own language with llvm as the base.
>
> I was working on string concatenation (where a string is just an array of
> characters cast to a pointer to a character (i8*) ). Given two strings, it
> is possible to determine the length of new string by summing the number of
> characters until the null terminator and adding one.
>
> Unfortunately, I have no idea how to use the c-api to store this. As the
> length of the new string is not a compile-time constant (e.g. stored in a
> Value*), I cannot determine at compile-time what length the llvm array-type
> will be? Therefore, I cannot create the GlobalVariable since I do not know
> the type.
>
> One possible solution I thought of was linking to the malloc function and
> calling that, but I'm sure there's a better way. If any of you have
> implemented a similar sort of string concatenation, I would much appreciate
> any advice that you could give.
>
> Thanks,
> Billy
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131014/8a968669/attachment.html>

However, how would one allocate the buffer for a string if you did not know
the length of the string at compile time?

For instance, using the api how would one reproduce the code for the
following c++ function?

std::string add(std::string a, std::string b){
  return a+b;
}

When allocating the buffer required for the new string, one can determine
the length at runtime, however I do not know how one can allocate a global
array with its size determined by a Value*.


On Mon, Oct 14, 2013 at 5:46 AM, Jeremy Lakeman <Jeremy.Lakeman at
gmail.com>wrote:
> The toy language I've been playing around with represents all strings
as a
> struct in llvm;
>
> struct string{
>   char *ptr;
>   int str_len;
>   int buffer_len;
> }
>
> And my AST has an interface like;
>
> String_AST{
>   int measure();
>   void copy(char *dest);
>   struct string get_value();
> }
>
> A constant string can be measured at compile time, for a string variable
> measure() just extracts str_len. Strings passed in from other external
> sources are measured immediately, but llvm optimisations will eliminate the
> call if the return value isn't used.
>
> The implementation of get_value() for a concatenation AST node can
> generate code to evaluate each sub string, measure them, allocate the final
> buffer length, and only then copy each sub string directly into the final
> buffer.
>
> I also support a string append operation that will reallocate the buffer
> only if the existing one is too small.
>
> Ultimately you will need to work out if you want pascal / java style
> strings like mine, or C style NULL terminated strings. And how the memory
> for these strings will be managed.
>
>
> On Sun, Oct 13, 2013 at 4:43 AM, William Moses <
> moses.williamsteven at gmail.com> wrote:
>
>> All,
>>
>> I am building my own language with llvm as the base.
>>
>> I was working on string concatenation (where a string is just an array
of
>> characters cast to a pointer to a character (i8*) ). Given two strings,
it
>> is possible to determine the length of new string by summing the number
of
>> characters until the null terminator and adding one.
>>
>> Unfortunately, I have no idea how to use the c-api to store this. As
the
>> length of the new string is not a compile-time constant (e.g. stored in
a
>> Value*), I cannot determine at compile-time what length the llvm
array-type
>> will be? Therefore, I cannot create the GlobalVariable since I do not
know
>> the type.
>>
>> One possible solution I thought of was linking to the malloc function
and
>> calling that, but I'm sure there's a better way. If any of you
have
>> implemented a similar sort of string concatenation, I would much
appreciate
>> any advice that you could give.
>>
>> Thanks,
>> Billy
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131014/89c9f90c/attachment.html>