thr3ads.net - llvm dev - [llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang [Jun 2019]

If this information is useful, please help other people find it:
Share via:

Tingyuan LIANG via llvm-dev

2019-Jun-30 05:48 UTC

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang

Dear David,

    Thanks for your prompt reply!
    Sure, I can implement a AST visitor to go through the AST to get the
information but I just wonder whether there is any other way to let Clang do so.
    What I am considering is how to let the generated IR looks like below, which
some tools realize:

define dso_local i32 @_Z1fPii([51 x i32]* %A, i32 %x) local_unnamed_addr #0 !dbg
!7 {
entry:
...
}

Best regards,
------------------------------------------
Tingyuan LIANG
MPhil Student
Department of Electronic and Computer Engineering
The Hong Kong University of Science and Technology
________________________________
From: David Blaikie <dblaikie at gmail.com>
Sent: Sunday, June 30, 2019 1:40 PM
To: Tingyuan LIANG
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Information Loss of Array Type in Function Interface in
IR Generated by Clang

LLVM IR doesn't maintain a lot of information present in the source. What
were you hoping to do with that information? Perhaps you'd be best off doing
something up in clang/using the AST uinstead of LLVM IR?

On Sat, Jun 29, 2019 at 10:36 PM Tingyuan LIANG via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear all,

    Hi! Recently, I notice a situation where I cannot infer the size of the
outermost dimension of array in the function interface.
    To concretely depict the problem, I show the C source code and the generated
IR code at the end. The array size of A[] is 51 but this information is lost in
the generated IR.
    How can I maintain such information in IR? Should I set some argument for
Clang so it can do so?
    The Clang command I used is :

     clang -O1 -emit-llvm -S -g tmp.cc -o tmp.bc

    Thanks in advance for your time and suggestion! ^_^

C source code:
int f ( int A[51], int x)
{
    return A[x];
}

==========================generated IR:
; Function Attrs: norecurse nounwind readonly uwtable
define dso_local i32 @_Z1fPii(i32* nocapture readonly %A, i32 %x)
local_unnamed_addr #0 !dbg !7 {
entry:
  call void @llvm.dbg.value(metadata i32* %A, metadata !13, metadata
!DIExpression()), !dbg !15
  call void @llvm.dbg.value(metadata i32 %x, metadata !14, metadata
!DIExpression()), !dbg !16
  %idxprom = sext i32 %x to i64, !dbg !17
  %arrayidx = getelementptr inbounds i32, i32* %A, i64 %idxprom, !dbg !17
  %0 = load i32, i32* %arrayidx, align 4, !dbg !17, !tbaa !18
  ret i32 %0, !dbg !22
}


Best regards,
------------------------------------------
Tingyuan LIANG
MPhil Student
Department of Electronic and Computer Engineering
The Hong Kong University of Science and Technology
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190630/18f9794d/attachment.html>

David Blaikie via llvm-dev

2019-Jun-30 05:51 UTC

head link

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang

There isn't any option to do that - because it doesn't model the
language
accurately (well, ultimately, one of these days, we'll get rid of pointer
types (everything will just be "pointer" (sort of like C's
'void*') - not
specific to the thing it points to) at which point none of this will ever
be represented in the IR) - the C language ignores the array portion (so
you can pass this function a pointer to a single int, or 3 ints, not
exactly 51 ints) entirely, degrading it to a pointer as far as semantics
are concerned.

On Sat, Jun 29, 2019 at 10:48 PM Tingyuan LIANG <tliang at connect.ust.hk>
wrote:
> Dear David,
>
>     Thanks for your prompt reply!
>     Sure, I can implement a AST visitor to go through the AST to get the
> information but I just wonder whether there is any other way to let Clang
> do so.
>     What I am considering is how to let the generated IR looks like below,
> which some tools realize:
>
> define dso_local i32 @_Z1fPii([51 x i32]* %A, i32 %x) local_unnamed_addr
> #0 !dbg !7 {
> entry:
> ...
> }
>
> Best regards,
> ------------------------------------------
> Tingyuan LIANG
> MPhil Student
> Department of Electronic and Computer Engineering
> The Hong Kong University of Science and Technology
> ------------------------------
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Sunday, June 30, 2019 1:40 PM
> *To:* Tingyuan LIANG
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Information Loss of Array Type in Function
> Interface in IR Generated by Clang
>
> LLVM IR doesn't maintain a lot of information present in the source.
What
> were you hoping to do with that information? Perhaps you'd be best off
> doing something up in clang/using the AST uinstead of LLVM IR?
>
> On Sat, Jun 29, 2019 at 10:36 PM Tingyuan LIANG via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Dear all,
>
>     Hi! Recently, I notice a situation where I cannot infer the size of
> the outermost dimension of array in the function interface.
>     To concretely depict the problem, I show the C source code and the
> generated IR code at the end. The array size of A[] is 51 but this
> information is lost in the generated IR.
>     How can I maintain such information in IR? Should I set some argument
> for Clang so it can do so?
>     The Clang command I used is :
>
>      clang -O1 -emit-llvm -S -g tmp.cc -o tmp.bc
>
>     Thanks in advance for your time and suggestion! ^_^
>
> C source code:
> int f ( int A[51], int x)
> {
>     return A[x];
> }
>
> ==========================> generated IR:
> ; Function Attrs: norecurse nounwind readonly uwtable
> define dso_local i32 @_Z1fPii(i32* nocapture readonly %A, i32 %x)
> local_unnamed_addr #0 !dbg !7 {
> entry:
>   call void @llvm.dbg.value(metadata i32* %A, metadata !13, metadata
> !DIExpression()), !dbg !15
>   call void @llvm.dbg.value(metadata i32 %x, metadata !14, metadata
> !DIExpression()), !dbg !16
>   %idxprom = sext i32 %x to i64, !dbg !17
>   %arrayidx = getelementptr inbounds i32, i32* %A, i64 %idxprom, !dbg !17
>   %0 = load i32, i32* %arrayidx, align 4, !dbg !17, !tbaa !18
>   ret i32 %0, !dbg !22
> }
>
>
> Best regards,
> ------------------------------------------
> Tingyuan LIANG
> MPhil Student
> Department of Electronic and Computer Engineering
> The Hong Kong University of Science and Technology
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190629/cc82a21d/attachment-0001.html>

Tingyuan LIANG via llvm-dev

2019-Jun-30 06:01 UTC

head link

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang

Dear David,

    Thanks for your detailed explanation! I get it!
    ^_^

Best regards,
------------------------------------------
Tingyuan LIANG
MPhil Student
Department of Electronic and Computer Engineering
The Hong Kong University of Science and Technology
________________________________
From: David Blaikie <dblaikie at gmail.com>
Sent: Sunday, June 30, 2019 1:51 PM
To: Tingyuan LIANG
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Information Loss of Array Type in Function Interface in
IR Generated by Clang

There isn't any option to do that - because it doesn't model the
language accurately (well, ultimately, one of these days, we'll get rid of
pointer types (everything will just be "pointer" (sort of like C's
'void*') - not specific to the thing it points to) at which point none
of this will ever be represented in the IR) - the C language ignores the array
portion (so you can pass this function a pointer to a single int, or 3 ints, not
exactly 51 ints) entirely, degrading it to a pointer as far as semantics are
concerned.

On Sat, Jun 29, 2019 at 10:48 PM Tingyuan LIANG <tliang at
connect.ust.hk<mailto:tliang at connect.ust.hk>> wrote:
Dear David,

    Thanks for your prompt reply!
    Sure, I can implement a AST visitor to go through the AST to get the
information but I just wonder whether there is any other way to let Clang do so.
    What I am considering is how to let the generated IR looks like below, which
some tools realize:

define dso_local i32 @_Z1fPii([51 x i32]* %A, i32 %x) local_unnamed_addr #0 !dbg
!7 {
entry:
...
}

Best regards,
------------------------------------------
Tingyuan LIANG
MPhil Student
Department of Electronic and Computer Engineering
The Hong Kong University of Science and Technology
________________________________
From: David Blaikie <dblaikie at gmail.com<mailto:dblaikie at
gmail.com>>
Sent: Sunday, June 30, 2019 1:40 PM
To: Tingyuan LIANG
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Information Loss of Array Type in Function Interface in
IR Generated by Clang

LLVM IR doesn't maintain a lot of information present in the source. What
were you hoping to do with that information? Perhaps you'd be best off doing
something up in clang/using the AST uinstead of LLVM IR?

On Sat, Jun 29, 2019 at 10:36 PM Tingyuan LIANG via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear all,

    Hi! Recently, I notice a situation where I cannot infer the size of the
outermost dimension of array in the function interface.
    To concretely depict the problem, I show the C source code and the generated
IR code at the end. The array size of A[] is 51 but this information is lost in
the generated IR.
    How can I maintain such information in IR? Should I set some argument for
Clang so it can do so?
    The Clang command I used is :

     clang -O1 -emit-llvm -S -g tmp.cc -o tmp.bc

    Thanks in advance for your time and suggestion! ^_^

C source code:
int f ( int A[51], int x)
{
    return A[x];
}

==========================generated IR:
; Function Attrs: norecurse nounwind readonly uwtable
define dso_local i32 @_Z1fPii(i32* nocapture readonly %A, i32 %x)
local_unnamed_addr #0 !dbg !7 {
entry:
  call void @llvm.dbg.value(metadata i32* %A, metadata !13, metadata
!DIExpression()), !dbg !15
  call void @llvm.dbg.value(metadata i32 %x, metadata !14, metadata
!DIExpression()), !dbg !16
  %idxprom = sext i32 %x to i64, !dbg !17
  %arrayidx = getelementptr inbounds i32, i32* %A, i64 %idxprom, !dbg !17
  %0 = load i32, i32* %arrayidx, align 4, !dbg !17, !tbaa !18
  ret i32 %0, !dbg !22
}


Best regards,
------------------------------------------
Tingyuan LIANG
MPhil Student
Department of Electronic and Computer Engineering
The Hong Kong University of Science and Technology
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190630/a8f11fbb/attachment.html>

llvm dev - Jun 2019 - Information Loss of Array Type in Function Interface in IR Generated by Clang

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang

[llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang